Emby Wiedergabefehler bei Abspielen von MP4 Streams

Ich deiner Server Info stehen einige Error Meldungen, z.B. die hier:

Zitat

&api_key=‌2d61d06bbbca44b9aae63b793a0f36cc‌&VideoCodec=h264,h265,hevc,av1,mpeg2video&AudioCodec=ac3,aac,mp3,opus&VideoBitrate=199840000&AudioBitrate=160000&MaxWidth=3840&AudioStreamIndex=1&TranscodingMaxAudioChannels=6&SegmentContainer=ts&MinSegments=1&BreakOnNonKeyFrames=False&SubtitleStreamIndexes=-1&ManifestSubtitles=vtt&h264-profile=high,main,baseline,constrainedbaseline,high10&h264-level=52&TranscodeReasons=DirectPlayError. Source Ip: ‌‍‍192.168.178.103‌, Accept=*/*, Connection=Upgrade, Host=‌‍‍192.168.178.60:8096‌, User-Agent=samsung-agent/1.1, Accept-Encoding=deflate, gzip, Upgrade=h2c, HTTP2-Settings=AAMAAABkAARAAAAAAAIAAAAA

Remuxen?! Entweder wieder als mp4 oder mkv.

Zitat von puenktchen

Remuxen?! Entweder wieder als mp4 oder mkv.

Wäre jetzt auch mein Vorschlag gewesen. Einfach mal mit MKVToolNix in nen mkv Container packen, dauert weniger als ne Minute.

Zitat von olli14

Der Emby Server soll NICHT transkodieren.

Dir ist schon aufgefallen, dass aber transkodiert wird, laut deinem ffmpeg log geht genau das schief? Und im Emby log steht beispielsweise: 2024-12-26 09:56:13.506 Info App: User policy for Sandra. EnablePlaybackRemuxing: True EnableVideoPlaybackTranscoding: True EnableAudioPlaybackTranscoding: True Bin da kein Experte, aber unter Einstellungen -> Server -> Benutzer gibt es Einstellungen zu Transcoding.

Den ersten Fehler, den ich auf Anhieb sehe ist der Zugriff auf Trakt. Kenne mich damit nicht aus, aber vielleicht hilft dir der Hinweis. Der Fehler erfolgt Millisekunden, nachdem das Streaming starten soll.

Liegen die Filme auf Freigaben?

Emby nutzt im Log weiterhin ffmpeg zum Konvertieren des mp4 in Hyptertext Live Streaming (HLS) Format (so interpretiere ich die Kommandozeile). Also nicht "Direct Play" was deinem Abspielen des Files auf der Fritzbox entsprechen würde. Offenbar passieren Fehler bei dieser HLS-Verarbeitung in Emby. Vielleicht kannst du auf Client-Seite was einstellen, dass Direct Play funktioniert. Aber das wäre nur ein Workaround. Nach meinem Verständnis sollte das schon klappen. Und HLS ist für Streaming grundsätzlich schon das bessere Format, als direkt mp4 oder ts oder mkv zu streamen, weil es Aufsetzpunkte bietet (wenn mal was schiefgeht mit einem Segment, kann mit dem nächsten weitergemacht werden bzw. das Segment leicht nochmals angefordert werden).

Die Wandlung in HLS geschieht über das Filesystem (nicht im RAM). Hast du genügend Speicher frei /config/transcoding-temp?

Ich kenne den ffmpeg Schalter -print_graphs_file nicht. Kannst dir aber mal /config/logs/ffmpeg-directstream-cd4eac91-72b3-42d2-94a5-8adb50e89187_1graph.txt ansehen, ob da was hilfreiches drinsteht. Genauso kannst mal das Verzeichnis /config/transcoding-temp/7F4F92/ anschauen. Ich vermute da sollten viele Files liegen 7F4F92_1.ts, 7F4F92_2.ts mit jeweils 6 Sekunden Video (die Segmente des HLS). Die Namen werden sich bei erneutem Versuch ändern. Ich würde mir auch noch ansehen, ob der ffmpeg-Prozess läuft (z.B. mit top) und ob er viel/zu viel CPU benötigt (sollte nicht der Fall sein ohne Transcoding).

Je nach Ergebnis kannst du auch nochmal mit den Einstellungen zu "Erlaube Medienkonvertierung" und "Erlaube Video-Wiedergabe mittels Konvertierung ohne Neu-Enkodierung" rumspielen. Vermute aber, dass er dann nicht abspielt, da Emby glaubt, dass das dein Client benötigt.

Ist das schon das log mit dem aktivierten debug logging in Emby?

das bitte auf ja schalten! dann kommen richitg Infos bei raus.

btw. ich weiß nicht ob der dort aufgeführte emby-token sichtbar sein sollte. Ich würde vorsichtshalber "Emby-Token=‌2d61d06b..." entfernen. Zumindest halt den Zeichenkette. Wenn nicht so einfach für dich machbar ist gib Bescheid, kann ich für dich auch machen.

Nun hast du offenbar weitere Einstellungen geändert *bevor* du die Checks gemacht hast (CPU, Files in transcoding-tmp, ...), Ich sehe z.B.: EnablePlaybackRemuxing: False. Damit wird ffmpeg nicht mehr aufgerufen, die temporären Files für HLS werden nicht erzeugt, das ffmpeg-Logfile wird nicht erzeugt. Mir scheint, der emby-Client auf dem Samsung TV kann den Film ohne Remuxing einfach nicht abspielen. Hatte ich auch so befürchtet oben. Daher könnte es hilfreich, die genannten Checks mit den alten Parametern zu machen.

Den Vorschlag von Publish3r oben zu wiederholen mit den veränderten Einstellungen könnte auch noch Sinn machen. Evt. auch wandeln in .ts (weil halt HLS auf ts basiert, und Emby Server das laut früheren Logs für notwendig hielt). Wandeln in .ts geht mit ffmpeg, z.B. sowas wie /bin/ffmpeg -i "/Movies/22 Kugeln.mp4" -map 0 -c copy -copy_unknown "/Movies/22 Kugeln.ts" (ungetestet, nur erschlossen aus deinem Log).

Kannst du mal deine beiden mp4 Dateien mit Media Info vergleichen und am besten unter view eine detailliertere Ansicht nehmen, vielleicht fällt dir dort was auf?

Ich habe mal in 2 Files reingeschaut. Bei erster Versuch wird ffmpeg erfolgreich gestartet, und es schreibt auch die .ts Segmente für HLS, bis Segment 9. Dann wird ffmpeg wieder gestoppt:

025-01-22 16:49:54.893 Info App: ProcessRun 'StreamTranscode 58fafd': Stopping ffmpeg process with q command for /config/transcoding-temp/F59A45/F59A45_0.ts

Warum kann vielleicht Emby-Experte rausfinden. ffmpeg Prozess lief soweit fehlerfrei.

Wieso 22 Kugeln ffmpeg benötigt, Dampfnudelblues jedoch nicht, sollte auch Emby Experte sehen können im Log. Ich habe mal in die Mediathek gesehen. 22 Kugeln gibt es nur von 3sat. Laut ffmpeg in deinem Log sehen die CODECS so aus:

16:49:54.511 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/Movies/22 Kugeln.mp4':
16:49:54.511   Metadata:
16:49:54.511     major_brand     : mp42
16:49:54.511     minor_version   : 1
16:49:54.511     compatible_brands: isommp42
16:49:54.511     creation_time   : 2024-09-14T10:51:39.000000Z
16:49:54.511   Duration: 01:44:47.92, start: 0.000000, bitrate: 5385 kb/s
16:49:54.512   Stream #0:0[0x1](deu): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 5215 kb/s, Level 42, 50 fps, 50 tbr, 1k tbn (default)
16:49:54.512     Metadata:
16:49:54.512       creation_time   : 2024-09-14T10:51:39.000000Z
16:49:54.512       handler_name    : GPAC ISO Video Handler
16:49:54.512       vendor_id       : [0][0][0][0]
16:49:54.512   Stream #0:1[0x2](deu): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 160 kb/s (default)
16:49:54.512     Metadata:
16:49:54.512       creation_time   : 2024-09-14T10:51:39.000000Z
16:49:54.512       handler_name    : GPAC ISO Audio Handler
16:49:54.512       vendor_id       : [0][0][0][0]

Dampfnudelblues gibt es vielfach in der Mediathek. 3sat Download sieht so aus

Duration: 01:26:48.92, start: 0.000000, bitrate: 5487 kb/s
 Stream #0:0[0x1](deu): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 5317 kb/s, 50 fps, 50 tbr, 1k tbn (default)
     Metadata:
       creation_time   : 2024-01-15T16:47:17.000000Z
       handler_name    : GPAC ISO Video Handler
       vendor_id       : [0][0][0][0]
 Stream #0:1[0x2](deu): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 160 kb/s (default)
     Metadata:
       creation_time   : 2024-01-15T16:47:17.000000Z
       handler_name    : GPAC ISO Audio Handler
       vendor_id       : [0][0][0][0]

Fast identisch, aber nicht ganz - z.B. Level42 fehlt (zeigt allerdings mein ffprobe auch nicht an beim 3sat Download). Anderer sieht so aus

Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 3412 kb/s, 50 fps, 50 tbr, 12800 tbn (default)
     Metadata:
       handler_name    : Hessischer Rundfunk mp4toolbox 1.17.0
       vendor_id       : [0][0][0][0]
       encoder         : Lavc61.3.100 libx264
 Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)
     Metadata:
       handler_name    : Hessischer Rundfunk mp4toolbox 1.17.0
       vendor_id       : [0][0][0][0]

Andere Audio-Rate, tbn anders (keine Ahnung was das heißt). Scheint auch noch eine Datei mit 25 fps zu geben. Irgendwas scheint Emby bei den leicht unterschiedlichen CODECs/Bitraten dazu veranlassen, ein Mal ffmpeg anzuwerfen, ein Mal nicht. Aber das ist nicht das ganze Problem. Auch wenn das benötigt würde - jemand kann vielleicht rausfinden, wieso der Transcoding Prozess wieder gestoppt wird.

Die Beispiele ändern sich (am Anfang war Bilder eines Jahres, dann 22 Kugeln), da war dann Conversion failed im ffmpeg Log, jetzt nicht mehr. Habe aber nicht alle Dateien angesehen.

Zitat von olli14

Es macht für mich auch keinen Sinn, runtergeladene MP4 Dateien irgendwie umzuwandeln

Jedenfalls von mir war das nicht als Workaround gemeint, sondern als Hilfe zur Analyse des Problems. Ich gebe dir recht - das sollte einfach funktionieren.

Wenn hier niemand helfen kann, wende dich doch an den Support von Emby.

Hast du ffprobe? Kannst du mal ffprobe "/Movies/Dampfnudelblues.mp4" ausführen, und Ergebnis hier posten (nicht als Anhang, nur Copy+Paste wie ich das oben gemacht habe, ab Input #0 Zeile). Das gleiche noch für 22 Kugeln. (Ergibt im Prinzip ähnliche Info wie die Frage von bennySB)

Ganz blöde Idee um es zu bestätigen:

22 Kugeln mit Handbrake o.v. Auf Konstante Bitrate umwandeln und schauen ob es damit läuft.

Sollte es dann gehen, dann ab mit dir ins Emby Forum und den Fall dort schildern mit den nachweisen.