Transcoding causing playback failure from .strm files

[bruor 43]

@Luke, @Happy2PlayI have made some progress here.  I've ruled out provider API and content mixing as a potential issue.  I am testing this using the docker container on the current stable release. 

I created a proxy that downloads the file from the provider and serves it up over HTTP.  I took that file, put it on my network share and ran ffprobe against the file from both sources to ensure the ffprobe output is identical. 

This is the output, identical from both sources: 
 

  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.76.100
  Duration: 01:56:14.13, start: 0.000000, bitrate: 9232 kb/s
  Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1920x800 [SAR 1:1 DAR 12:5], 8968 kb/s, Level 40, 23.98 fps, 23.98 tbr, 16k tbn (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
  Stream #0:1[0x2](eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 5.1, fltp, 256 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]
  Stream #0:2[0x3](eng): Data: bin_data (text / 0x74786574)
    Metadata:
      handler_name    : SubtitleHandler
Unsupported codec with id 98314 for input stream 2

However,  if I play the file from my NAS (with or without transcoding) it works as expected: 
 

Server Log:
Execute: /bin/ffmpeg -loglevel +timing -y -print_graphs_file "/config/logs/ffmpeg-transcode-4e2104c2-10ef-43d4-8591-c93839dace90_1graph.txt" -copyts -start_at_zero -init_hw_device "qsv=dev1:hw_any,child_device=/dev/dri/renderD128" -filter_hw_device dev1 -f mp4 -ss 00:00:03.000 -c:v:0 h264_qsv -threads:v:0 1 -hwaccel:v:0 qsv -hwaccel_output_format:v:0 qsv -noautorotate -i "/mnt/media/movies/A Working Man (2025)/A Working Man (2025).mkv" -map 0:0 -map 0:1 -sn -c:v:0 h264_qsv -b:v:0 3744001 -g:v:0 72 -maxrate:v:0 3744001 -bufsize:v:0 7488002 -keyint_min:v:0 72 -r:v:0 23.976024627685547 -profile:v:0 high -aud:v:0 1 -c:a:0 copy -metadata:s:a:0 language=eng -disposition:a:0 default -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1 -map_chapters -1 -segment_format mpegts -segment_list "/config/transcoding-temp/3E5A76/3E5A76.m3u8" -segment_list_type m3u8 -segment_time 00:00:03.000 -segment_start_number 1 -individual_header_trailer 0 -write_header_trailer 0 -segment_write_temp 1 "/config/transcoding-temp/3E5A76/3E5A76_%d.ts"

But if I try to play from http source, it doesn't:

Server Log: 
Execute: /bin/ffmpeg -loglevel +timing -y -print_graphs_file "/config/logs/ffmpeg-transcode-66f1ded4-f2b9-470f-b823-50228f9c4863_1graph.txt" -copyts -start_at_zero -init_hw_device "qsv=dev1:hw_any,child_device=/dev/dri/renderD128" -filter_hw_device dev1 -f matroska,webm -c:v:0 h264_qsv -threads:v:0 1 -hwaccel:v:0 qsv -hwaccel_output_format:v:0 qsv -noautorotate -i "http://172.31.0.102:8080/u/base64url" -map 0:0 -map 0:1 -sn -c:v:0 h264_qsv -b:v:0 3616002 -g:v:0 72 -maxrate:v:0 3616002 -bufsize:v:0 7232004 -keyint_min:v:0 72 -r:v:0 23.976024627685547 -profile:v:0 high -aud:v:0 1 -c:a:0 libmp3lame -ab:a:0 192000 -ac:a:0 2 -metadata:s:a:0 language=eng -filter:a:0 "volume=2" -disposition:a:0 default -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1 -map_chapters -1 -segment_format mpegts -segment_list "/config/transcoding-temp/D08B9F/D08B9F.m3u8" -segment_list_type m3u8 -segment_time 00:00:03.000 -segment_start_number 0 -individual_header_trailer 0 -write_header_trailer 0 -segment_write_temp 1 "/config/transcoding-temp/D08B9F/D08B9F_%d.ts" -map 0:2 -map 0:0 -an -c:v:0 copy -c:s:0 webvtt -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1 -segment_format webvtt -segment_list "/config/transcoding-temp/D08B9F/D08B9F_s2.m3u8" -segment_list_type m3u8 -segment_time 00:00:03.000 -segment_start_number 0 -break_non_keyframes 1 -individual_header_trailer 1 -write_header_trailer 0 -write_empty_segments 1 -segment_write_temp 1 -min_frame_time 00:00:00.000 "/config/transcoding-temp/D08B9F/D08B9F_s2_%d.vtt" -map 0:3 -map 0:0 -an -c:v:0 copy -c:s:0 webvtt -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1 -segment_format webvtt -segment_list "/config/transcoding-temp/D08B9F/D08B9F_s3.m3u8" -segment_list_type m3u8 -segment_time 00:00:03.000 -segment_start_number 0 -break_non_keyframes 1 -individual_header_trailer 1 -write_header_trailer 0 -write_empty_segments 1 -segment_write_temp 1 -min_frame_time 00:00:00.000 "/config/transcoding-temp/D08B9F/D08B9F_s3_%d.vtt" -map 0:4 -map 0:0 -an -c:v:0 copy -c:s:0 webvtt -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1 -segment_format webvtt -segment_list "/config/transcoding-temp/D08B9F/D08B9F_s4.m3u8" -segment_list_type m3u8 -segment_time 00:00:03.000 -segment_start_number 0 -break_non_keyframes 1 -individual_header_trailer 1 -write_header_trailer 0 -write_empty_segments 1 -segment_write_temp 1 -min_frame_time 00:00:00.000 "/config/transcoding-temp/D08B9F/D08B9F_s4_%d.vtt"

Transcode log: 
[matroska,webm @ 0x8155d00] 0x00 at pos 0 (0x0) invalid as first byte of an EBML number
[matroska,webm @ 0x8155d00] EBML header parsing failed
http://172.31.0.102:8080/u/base64url: Invalid data found when processing input

I initially thought this might be header related as suggested earlier, so I used curl to verify the content-type sent back by my proxy.  It was defaulting to application/octet-stream, so I tried forcing it over to video/mp4, but it makes no difference in the ffprobe output, or my ability to play the media.
 

*   Trying 172.31.0.102:8080...
* Connected to 172.31.0.102 (172.31.0.102) port 8080
> GET /u/base64url HTTP/1.1
> Host: 172.31.0.102:8080
> Range: bytes=0-1023
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 206 Partial Content
< Server: openresty/1.27.1.2
< Date: Mon, 24 Nov 2025 14:17:00 GMT
< Content-Type: video/mp4
< Content-Length: 1024
< Last-Modified: Sat, 22 Nov 2025 04:00:59 GMT
< Connection: keep-alive
< X-Cache: HIT
< ETag: "6921357b-1dfbd0e72"
< Accept-Ranges: bytes
< Content-Range: bytes 0-1023/8048676466

As you can see from the server logs above, emby is choosing an incompatible transcoding command when the file is being read from an http source even with the content-type set. 
 

from disk: -f mp4
from  web: -f matroska,webm

 

Edited November 24, 2025 by bruor

[Luke 42077]

Right there's something causing ffprobe to see the container as mov/mp4 that we don't know yet.

[bruor 43]

Ok, if there's anything else you need debugging wise that I can send over for inspection let me know.  

I've done some pretty extensive testing to make sure that I'm serving up a perfect set of bytes.  And since ffprobe seems to detect the file correctly I can only assume there's some built-in logic in the code coming into play when the file source is a webserver. 

[bruor 43]

I patched my proxy so that I could put a file extension on the URL that is in the .strm file as a workaround and it resolves the type detection issue.  This isn't a workable solution though since IPTV providers tend to use APIs to serve up content and restrict access to media.  

Functionally it seems like ffprobe is able to detect the media attributes properly:

./emby-ffprobe -v trace -show_format -show_streams http://172.31.0.102:8080/u/base64url 2>&1 | grep -i 'score'
Probing mov,mp4,m4a,3gp,3g2,mj2 score:100 size:2048
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x103b77c0] Format mov,mp4,m4a,3gp,3g2,mj2 probed with size=2048 and score=100
probe_score=100

And so is ffmpeg:

./emby-ffmpeg -v trace -i http://172.31.0.102:8080/u/base64url -f null 2>&1 | grep -i 'score\|Format '
  libavformat    59. 27.100 / 59. 27.100
Probing mov,mp4,m4a,3gp,3g2,mj2 score:100 size:2048
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x150a1100] Format mov,mp4,m4a,3gp,3g2,mj2 probed with size=2048 and score=100
[h264 @ 0x150a5800] Format yuv420p chosen by get_format().

There must be some logic at play internally (which composes the ffmpeg transcoding command) that isn't trusting the media detection output and deciding to fall back to some other default value when the file extension is not present. 

[bruor 43]

I've had a chance to test an entire series of episodes and modifying the url seems to only work in select cases.  However, I have determined that deleting the offending media from the library and re-adding it resolves the issue. 

@LukeCan you share some insight into why this might be the fix and what is happening under the hood here?    I assume that some type of information is being stored about the media in the database/nfo that is incorrect and is not being updated at playback time.  This is likely due to provider side content changes behind their API.  Is there configuration I can change or a way for me to use the API (or direct database access) to proactively sweep through the library and clear out any of this data so that it can be re-created properly when content is played?  Ideally I'd like to not need to delete and re-add offending content to the library to cut down on metadata scans and to keep older media from being resurfaced in the "Latest" feeds.  It looks like refreshing the metadata for offending items works but I have to call it for every piece of content, doing this as the series level doesn't work. 

 

Edited November 27, 2025 by bruor

[bruor 43]

For the time being I've written a helper service in python that uses filesystem level notifications as new logs are created and tails them for a few seconds to see if an error is generated.  If so it grabs the item number from the log and calls a metadata refresh using the API. 

If the plugin architecture allow for similar hooks and actions I'd be happy to refactor it so I can install it as something that runs within my emby servers instead of having to manage it as an external service.  Will share a link to the repo once I think it's complete. 

Edited November 27, 2025 by bruor

[bruor 43]

https://github.com/bruor/EmbyContentWatchdog