| Предыдущий | Следующий |
| NS_S_DEGRADING_QUALITY | NS_S_WMP_UI_VERSIONMISMATCH |
NS_S_TRANSCRYPTOR_EOF
Windows Media transcryptor достиг конца файла
NS_S_TRANSCRYPTOR_EOF — это HRESULT 855003 (0x000D0BDB) Windows Media. В AllStat он описан как «объект transcryptor достиг конца файла». Бит severity указывает на неошибочный результат, однако значение передаёт конкретное состояние, которое нельзя сводить к обычному S_OK.
В устаревшем конвейере Windows Media или состоянии Player этот статус означает, что объект transcryptor достиг конца файла. Прежде чем сообщать о завершении после этого статусазавершённым, вызывающий код должен согласовать специфичный для этого кода переход состояния и все пригодные выходные данные.
Где встречается этот статус
- Этот статус может возвращаться в callbacks источника, reader, writer или renderer Windows Media; фиксируйте точный метод и состояние объекта, а не интерпретируйте константу вне контракта этого вызова.
- Этот статус может возвращаться при автоматизации через Windows Media Player SDK; фиксируйте точный метод и состояние объекта, а не интерпретируйте константу вне контракта этого вызова.
- Этот статус может возвращаться в состояниях media graph, playlist, image, rights или buffering; фиксируйте точный метод и состояние объекта, а не интерпретируйте константу вне контракта этого вызова.
Поскольку этот статус является информационным статусом, языковая оболочка может показать его как успех и скрыть символическое различие. Сохраняйте исходный HRESULT, пока не отработана ветвь, специфичная для этого кода.
Что должно быть истинно перед принятием результата
Для этого статуса убедитесь, что весь преобразованный до EOF вывод зафиксирован и конвейер прекращает работу, не запрашивая несуществующие входные данные. Без этого Этот статус может скрыть ошибку вызывающего кода, хотя бит severity этого HRESULT не указывает на сбой.
Перед компенсацией или вторым вызовом согласуйте побочные эффекты, связанные с этим статусом .
Данные и телеметрия
- Для этого статуса сохраните идентичность входного и выходного материала.
- Для этого статуса сохраните количество сэмплов и байтов.
- Для этого статуса сохраните последнюю временную отметку.
- Для этого статуса сохраните ожидаемую длительность.
- Для этого статуса сохраните результат финального сброса криптографического состояния или контейнера.
Также зафиксируйте ns_s_transcryptor_eof_operation, ns_s_transcryptor_eof_state_before, ns_s_transcryptor_eof_state_afterвремя UTC, идентификаторы процесса и потока, версию компонента и correlation ID. Телеметрия для этого статуса не должна содержать учётные данные, но должна сохранять несекретные идентификаторы объектов и сведения о версиях.
Последовательность диагностики
- Зафиксируйте исходное значение
0x000D0BDBдо того, как оболочки, знаковое десятичное форматирование, исключения или общая обработка успеха заменят исходный статус. - Определите операцию, вернувшую этот статус, включая интерфейс или callback, сборку компонента, поток, процесс и фазу машины состояний.
- Для этого статуса подтвердите решающее условие: весь преобразованный до EOF вывод зафиксирован, а конвейер остановлен без запросов несуществующих входных данных.
- Проверьте каждый выходной параметр, счётчик, массив статусов, буфер, callback, состояние задачи, временную метку медиа, голос транзакции или security token, остающийся частью контракта этого статуса.
- Сравните состояние непосредственно до и после этого статуса; success severity не гарантирует завершения необязательной работы или высокоуровневого действия, которого ожидал вызывающий код.
- Воспроизведите этот статус на минимальном входе, сохраняющем то же условие, затем измените только зафиксированную причину и повторите операцию.
Правильная обработка и восстановление
Сбросьте последние преобразованные блоки, безопасно закройте выходной объект и проверьте ожидаемое число элементов или длительность. Если EOF наступил раньше ожидаемого и счётчики не совпадают, рассматривайте это как отдельную проблему целостности.
Повторяйте операцию только после изменения документированного входа или состояния. Неизменный повтор после этого статуса полезен только если API документированно продвигается по состояниям при повторных вызовах.
Отличие от соседних результатов
Этот статус нужно отличать от обычного S_OK и от значений того же семейства API, у которых бит severity указывает на сбой; документированное состояние определяет следующее действие.
Правильное отделение этого статуса от соседних значений выбирает корректный путь продолжения и cleanup.
Практический сценарий
При переносе защищённого медиафайла достигается EOF после всех ожидаемых сэмплов. Transcryptor сбрасывает последний блок и перед закрытием проверяет длительность результата.
Регрессионный тест должен воспроизвести этот статус, проверить соответствующие выходные данные и состояние, затем изменить только решающее условие и убедиться в ожидаемом соседнем результате или обычном завершении.
Рекомендации разработчикам и администраторам
Когда этот статус проходит через границы COM, RPC, managed code, scripting или logging, сохраняйте беззнаковое 32-битное значение. Тесты должны проверять постусловие этого статуса, а не только то, что бит severity означает успех.
Для этого статуса документируйте владельца повторов, отмены, cleanup и пользовательских сообщений. Для этого статуса меняйте конфигурацию или состояние ответственного компонента только после того, как собранные данные подтвердят причинную связь.
Ссылки
- Microsoft: коды ошибок Windows Media Format SDK — официальный материал Microsoft для интерпретации этого статуса.
- Microsoft: Windows Media Player SDK — официальный материал Microsoft для интерпретации этого статуса.
- Microsoft: событие buffering в Windows Media Player — официальный материал Microsoft для интерпретации этого статуса.
- Microsoft: значения HRESULT — официальный материал Microsoft для интерпретации этого статуса.
Нужно найти другой код? Найти другой код состояния или ошибки.