Probleme mit Windows, firefox und NFS

[psyc_psyc 1]

Hey Ho Community,

 

wie Soll ich dieses Problem genau beziffern, oder die Probleme.

Seit dem Letzten Update auf dem Windows client mit der neuen Firefox Version 145, koennen die titel die keine Hinterlegtes Digitial right marker haben nicht mehr abgespielt werden, auf dem Linux client mit der Version 144 gings noch, allerdings auf 145 auch nicht mehr.

 

Dazu Kommt noch eine weitere Problematik, vll hab ich da auch selbst irgendwie verkackt.

 

Also Ausgangs Szenario:

EmbyServer ist eine VM auf meinem Proxmox Cluster, die Bibiothek die ich damit angebunden habe befindet sich auf einem Synlogie DSM 6.2 Raid 5 System, das ich naja per NFS gemountet habe in einem System Deman Service. Hatte bis zu einem Raid 5 Erweitern keine probleme mit der Anbindung, meine Geräte daheim konnten locker 5 clients zeitgleich bedinen, der VM ist eine Geforce 1070 Complett zur verfügung gestellt, also auch auswählbar im emby server.

Nun habe ich vor tagen im Synlogie platten gewechselt und das Volumen was sich auf dem RAID 5 Befinden erweitert ist nun 9TB gross.

So nun habe ich allerdings probleme mit den neuen Hinzugefügten Medien, der Scan erkennt Sie allerdings beim versuch abzuspielen habe ich komischerweisse die Gleichen Probleme, wie bei den Musik videos ohne DRM. 

Die RAID 5 Konsistenzprüfung ist ohne Fehler durchgelaufen, schiebe die files per scp als auf das volumen 11,3MB pro secunde, also leistung top MD5 Summen sind korrekt,

der HEAD Befehl kann auch die files (ok lese nur das 1k  davon aus abrufen)

 

So nun naja bin ich am Fehlersuchen.

Aktuell naja mach ich auch mal wieder viel zu viel auf einmal (an verscheidenen Sachen) Daher koennte Tipp fehler hier enthalten sein und eventuell ne falsche abkürzung.

Liegt mein Fehler an der Grosse des Möglichen anbindbaren Volum Grösse des NFS?

Finde auch auf anhieb leider die Funktion im Synlogy nicht das Volumen noch mal zu überprüfen.

Die Files überprüfe ich bevor ich die verschiebe auf dem Windows client mit VLC , da laufen Sie.

Daher stell ich mich mal wieder irgendwie zu Blöd an (Ueberdenke oft einiges zu viel)

 

Grüsse P5yc

[Luke 42077]

HI, what exactly happens when you try to play?

[psyc_psyc 1]

Hey Luke,

 

es kommt die Lade Animation, also der blau drehende Kreis und dann nichts mehr.

Die Funktionierenden medien sind inerhalb von non ner Secunde da und spielen ab,

es ist komisch das image Captering funtkioniert auch, also wenn er bei neuen medien auf anhieb nicht auflösen kann was es ist und ein Vorschaubild generiert.

Ich habe die Bibiothek schon komplett rausgehauen merhmals und hab sie neu eingehaengt und scannen lassen.

 

[Luke 42077]

   @psyc_psyc

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

 

[psyc_psyc 1]

Hey Luke,

 

okay, also Szenario. Emby Server Neugestartet für ein Saubere log (gehe davon aus logrotatet ist beim serverstart)

Eins der Files was betroffen ist habe ich auf play geklickt und ca nach 30 secunden dauer lade cyclus wieder abgebrochen.

Zum ausschliessen das das File corrubt ist , habe ich es mit scp vom server auf einen Client geladen und abgespielt mim vlc local funktioniert einwandfrei, daher die Datenintentität (fucking word) ist gegeben, das File ist nicht Corrupt.

Benötigst oder Sollte ich die Debug Funktion für ein Besseres Log aktivieren?

embyserver.txt

[Luke 42077]

Hi, can you try chrome and see how that compares? Thanks.

[Keenuts 2]

Hi Luke, psyc_psyc

I witnessed the same issue, but have recently witnessed it seems to be a behavior change between Firefox 144 and Firefox 145, and it only impacts some files
 - laptop was running FF 145: unable to load a video, but in some cases, sound does play after some time, but with a black screen.
 - desktop, FF 144, no issues running the same video
 - desktop, updated to FF 145, no longer able to get the video, black screen, same as laptop.

Chromium + Google Chrome both works fine
 

[psyc_psyc 1]

Hey Luke, Kennuts

 

ich habe gerade den Chrome runtergeladen, leider das selbe.

Habe es mit der Serie getestet die funktioniert hatte und nun nicht mehr, (Eureka S1 und S2 war ich dabei zu schauen bevor dieses passierte) habe es dann noch mal mit einem film probiert bei dem vermerkt wurde wo ich war, der funktionerte. 

Getestet habe ich Chrom aufem Windoof, koennte es sein das eventuell die Metadaten defekt sind, habe die 2 Bibliotheken nur entfernt und neu hinzugefügt (was mich etwas aufregt da diese Sehr gut Gepflegt waren mit Bildern Infos und Co kg)

ich haenge noch mal den log an, in dem die nicht funktionierrenden drin sind, also endless lade screen und auch ein funktionierendes mit dabei ist (Chrome getestet)

 

embyserver.txt

[psyc_psyc 1]

Hey Ho,

so die fehler das es das fileystem oder die anbindung sein kann ist nun ausgeschlossen,

ich habe mein laptop ausgekrammt (hust) auf dem schon laenger keien updates mehr gefahren sind.

Habe eins der videos was betroffen ist (also im aktuellen firefox und aktuellen chrome nicht funktionieren)

funktioniert mit der aelteren Firefox version.

ich haenge das log file an, (davor logrotatet angestossen)

 

embyserver.txt

[psyc_psyc 1]

Hm eine editir funktion im forum gibts wohl nicht, okay bei diesem gabs edit ^^.

Daher ein neuer Post

Also den unterschied den ich nun zwischen den zwei geräten gesehen habe ist , bzw zwischen den geräten ist.

Das er am Laptop das File in die Konvertierung als stream gibt.

Bild eins ist der fehlerhafte, also ihc klicke auf das medium er versucht ihn zu laden, klicke einmal auf das fenster, dann ladet er die hintergrund bilder und medien infos also name und co kg und zeigt in der uebersicht bild 1 an , alles direktwiedergabe.

Wenn ich am laptop mit der aelteren firefox version den titel abspiele (funktioniert instant) geht er in die konvertierung. Siehe bild 2

 

Edited December 8, 2025 by psyc_psyc

[Luke 42077]

HI, firefox recently added support for mkv direct play. It sounds like it is having trouble with certain mkv files.

 

[psyc_psyc 1]

Hi Luke,

Yes, I can narrow it down to certain files: It seems the issues are specifically occurring with the H.264 (HEVC) video encoder and AAC audio.

(Sorry, I previously wrote H.265, but I meant H.264

The quality settings (auto vs. max resolution) don't seem to make a difference; the problem persists on both.

How can I best help you to pinpoint the exact files or parameters causing this? Also, what is the best path forward—is there a way to manually force transcoding for these specific cases again, or how should we proceed to fix this?

Best regards

p5yc

Update: I’ve also edited this post to include a screenshot of the specific file properties. It shows the exact encoding details, including the H.264 profile and the AAC track information. Hopefully, this helps to verify if there's a specific mismatch with the new browser engines.

Edited December 8, 2025 by psyc_psyc
file attachment , edit codet

[psyc_psyc 1]

Hi Luke,

I’ve confirmed the issue: Emby incorrectly assumes Firefox can handle H.264 Level 4.2 MKVs via Direct Play. Forcing a bitrate limit (e.g., 12 Mbps) triggers the GPU transcoder and fixes playback, but this is a poor workaround as it limits my 4K local library as well.

Since re-encoding thousands of files to Level 4.1 isn't an option during my medical leave, here is my question:

Is there a way to modify the server's DLNA/Client profile for Firefox to flag 'Level 4.2' as unsupported? This would force the server to remux or transcode these specific files to 4.1 automatically for the web client without having to manually cap the entire local bitrate for 4K content.

Thanks again for your technical insight!

 

p.S.:

Update on Client Testing: Tomorrow, I will test this on the dedicated Emby Theater apps for both Linux (Kitchen TV) and Windows. I expect these will handle the files without issue since they don't rely on the restricted browser engines for Direct Play. This further points to a specific negotiation error between the Emby Server and modern browser MKV decoders regarding Level 4.2.

[Luke 42077]

hi, how did you determine that it doesn't support level 4.2?

[psyc_psyc 1]

Hi Luke,

Thank you for confirming the Level 4.2 behavior. I have more critical data, which narrows down the root cause even further.

I tested a clean file (H.264 Level 4.1 with AAC) and it also failed when streaming quality was set to 'Auto,' indicating the issue is not purely codec level or AC3, but with the MKV container itself during Direct Play in the new Firefox client.

Here is the log evidence:

• Failure Log (Auto Quality): The console output shows the player immediately failing with the message: Medien können nicht wiedergegeben werden. Keine Decoder für angefragte Formate... This indicates the browser is failing to decode the MKV file directly.

• Success Log (Limit Set): When I set the quality limit low enough to trigger transcoding, the stream immediately switches to HLS (master.m3u8) and plays without issue. The log confirms the reason: TranscodeReasons=ContainerBitrateExceedsLimit.

Conclusion:

The problem is that the new Firefox MKV Direct Play support is unreliable (or buggy) when used with the Emby Web Client.

The most effective fix would be for the server to recognize this and to automatically force Transcoding/Remuxing to HLS for all MKV container files delivered to the Firefox client, regardless of the H.264 Level, to avoid the failure cascade.

What is the recommended server profile configuration to force MKV Remuxing/Transcoding instead of Direct Play for the web client?

Thanks again for your perseverance on this. The data confirms my workaround is effective!

 

p.S.:

I have attached two separate logs to this post:

• firefox_console_output_file_without_transcoding_dircektplay.txt  (The initial failure without a bitrate limit)

• firefox_console_output_file_StreamingQuailiHomelan-1080p_10mbps.txt (The successful playback after setting the limit to 10 Mbps)

firefox_console_output_file_without_transcoding_dircektplay.txt firefox_console_output_file_StreamingQuailiHomelan-1080p_10mbps.txt

[Luke 42077]

Hi, if the player throws an error with the file, our app will catch that and automatically switch to transcoding. so no problem there.

However this case is different in that the player is not raising any error but it sounds like it's just hanging altogether. We currently don't have a way to disable the mkv support, but we'll keep an eye on it. Since this is all very new with firefox, I would imagine they will keep improving it.