Buffering

[pegasuspc 2]

for some reason emby has started buffering my Tom & Jerry Cartoons...I thought it might be a bad drive so I moved it to a different drive but it is still doing the same thing not sure why it started this out of the blue.

 

Thanks

Michael

embyserver.txt

[brothom 206]

@pegasuspclooking at your log shows the following:

2026-03-25 03:18:52.603 Info DynamicHlsService-0HNK9S9M0649M:00000011: http/1.1 GET http://host1:8096/emby/videos/205282/main.m3u8?DeviceId=92718231-502b-49ca-9624-a9568d7ca042&MediaSourceId=mediasource_205282&PlaySessionId=934924455beb410b81ef7cd041c3e002&api_key=x_secret1_x&VideoCodec=h264,av1&AudioCodec=mp3,aac&VideoBitrate=199808000&AudioBitrate=192000&AudioStreamIndex=1&TranscodingMaxAudioChannels=2&SegmentContainer=ts&MinSegments=1&BreakOnNonKeyFrames=False&SubtitleStreamIndexes=-1&ManifestSubtitles=vtt&h264-profile=high,main,baseline,constrainedbaseline,high10&h264-level=62&TranscodeReasons=VideoCodecNotSupported,AudioCodecNotSupported. Source Ip: host2, Accept=*/*, Connection=keep-alive, Host=host1:8096, User-Agent=Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36, Accept-Encoding=gzip, deflate, Accept-Language=en-US,en;q=0.9, Referer=http://host1:8096/web/index.html

Or more specifically: 

TranscodeReasons=VideoCodecNotSupported,AudioCodecNotSupported

It looks like the device you're using, doesn't seem to support both video and audio codecs of the provided file.

What device are you using to watch?
The filename contains "x265", indicating it's a HEVC encoded file. Chromecasts and/or Windows 10 devices don't support HEVC natively.

 

Edited 8 hours ago by brothom

[pegasuspc 2]

this happens on both Emby Theater and web app in Linuxmint 22.3

[Lessaj 484]

The ts chunks are taking ~2 seconds to be delivered, which is a very long time considering that later on it takes only a few ms to deliver. This probably means that it's transcoding at full speed for the whole file and then stops, but having said that 2 seconds is still fast enough to deliver without buffering since each chunk is 3 seconds long (-segment_time 00:00:03.000). Looks like your system is pretty slow to handle this, and there's no log entries for Theater to compare with, which should be able to direct play this file. Please include the ffmpeg transcode log as well.

BTW, why did you configure your transcoding temp folder to /data/radio/transcoding-temp when you have /data/radio as a library path? This is causing constant rescans of that folder - probably RTM is enabled for this library.

Quote

    Library:  internet radio, id: 141457, CollectionType: music, CollapseSingleItemFolders: False, ForceCollapseSingleItemFolders: False
    Configured paths: /data/radio
    Library Folder: radio, id: 141458: path: /data/radio

2026-03-25 03:20:22.643 Info LibraryMonitor: transcoding-temp (/data/radio/transcoding-temp) will be refreshed.