All Activity

I think I may have isolated this further, and despite the title of this thread, I don't believe AC-4 itself is necessarily the cause of the playback failure. I am seeing essentially the same problem described here with KTXL/FOX40 in Sacramento. This is an unencrypted ATSC 3.0 channel received through an HDHomeRun at v140.1. The channel previously worked in Emby. It currently works normally, with video and audio, using the HDHomeRun application. VLC also plays the HEVC video perfectly, but has no audio because my VLC installation does not decode AC-4. Emby, however, fails completely with: Playback Error No compatible streams are currently available. Playback failure: network I initially suspected AC-4, but the Emby FFmpeg log appears to point somewhere else. I am currently running Emby Server 4.10.0.40. The included FFmpeg identifies itself as: ffmpeg version 5.1-emby_2023_06_25_p6 Emby successfully probes the ATSC 3.0 transport stream and identifies: HEVC Main 10 video, 1920x1080, 59.94 fps, yuv420p10le English AC-4 5.1 audio Spanish AC-4 audio STPP/data/caption streams It then sets up a transcode of HEVC → H.264/libx264 and AC-4 → MP3/libmp3lame. In other words, the Emby FFmpeg build appears to recognize the AC-4 stream and has an AC-4 decoder available. However, before any frames are produced, the HEVC decoder repeatedly reports: [hevc] PPS id out of range: 0 Error parsing NAL unit #4. This repeats continuously, and ultimately zero video is produced. I then tested the HDHomeRun stream directly with a current FFmpeg installation, explicitly disabling audio so that AC-4 support was irrelevant: ffmpeg -hide_banner -loglevel info -i 'http://hd1.direct.webbnet.org:5004/auto/v140.1' -map 0:v:0 -an -t 15 -f null - The current FFmpeg/libavcodec successfully decoded the stream: Stream #0:0 -> #0:0 (hevc (native) -> wrapped_avframe (native)) and completed the 15-second test with: frame= 900 ... time=00:00:14.89 ... speed=6.59x There were no HEVC PPS/NAL parsing errors. The current FFmpeg could not determine the AC-4 audio parameters and reported the AC-4 streams as 0 channels/unspecified sample rate, which is expected since upstream FFmpeg does not provide the AC-4 support that Emby's customized build does. But that was deliberately excluded from this test with -an. So at this point I seem to have the following: HDHomeRun application: HEVC works, AC-4 works VLC: HEVC works, AC-4 does not Current upstream FFmpeg/libavcodec: HEVC works; AC-4 unavailable Emby's FFmpeg 5.1 build: AC-4 is recognized/supported, but HEVC decoding fails with repeated PPS id out of range: 0 This makes me wonder whether the actual regression is not AC-4 at all, but rather that Emby's custom AC-4-capable FFmpeg is still based on FFmpeg 5.1/2023 and its HEVC decoder is no longer handling something present in current ATSC 3.0 broadcasts. For comparison, before upgrading I was running Emby 4.9.5.0, whose included FFmpeg identified itself as: 5.1-emby_2023_06_25_p4 After upgrading to Emby 4.10.0.40, it is: 5.1-emby_2023_06_25_p6 The exact same HEVC PPS id out of range failure occurs with both versions. It therefore looks possible that Emby's AC-4 patches themselves are still doing what they are supposed to do, but the FFmpeg 5.1 codebase underneath them has become the compatibility problem. One additional test I can perform is to invoke /opt/emby-server/bin/ffmpeg directly against the HDHomeRun URL. That should distinguish between two possibilities: If Emby's bundled FFmpeg produces the same PPS errors when reading the HDHomeRun URL directly, this would strongly suggest the problem is the older HEVC/libavcodec implementation in the Emby FFmpeg build. If Emby's bundled FFmpeg successfully decodes the direct HDHomeRun stream, but fails when Emby feeds it the internal /LiveTv/LiveStreamFiles/.../stream.ts, then the problem would instead appear to be somewhere in Emby's Live TV ingest/repackaging/stream initialization path. Given that this ATSC 3.0 channel previously worked in Emby, VLC still decodes its video, and a current FFmpeg decodes all 900 frames of the 15-second test without error, I think the repeated HEVC PPS errors in the Emby FFmpeg log may be the most useful clue. I would be happy to provide the complete Emby FFmpeg log and perform additional A/B tests if that would help isolate it.

It easier than all that.... Use MP3TAG. Add album artist and artist tag to your music videos, nothing else (title should obviously already be there). Scan the library in emby and they will show up in the Music library. You would have to make some decisions on how to tag Movie sound tracks.

You might have to provide more details because in my case the new stable release did resolve the HW tone mapping.

Thank you for this. I went a slightly different route and put in a ping service which detects if my file server is up. I run emby through docker so I made that service a requirement of docker. to the original question/your reply. I get it doesn't know if it's intentionally purged, maybe a buffer before dumping the data, so if it's restored it doesn't require a rebuild.

The upcoming beta release?

Thanks

I was directed here by Ebr and I would like to see if we could have movie soundtracks pulled from movie folders into the music library? So Instead of moving or separating the original movie soundtrack from the actual movie folder (it can stay within the folder) Example: Movie Folder 300 (year) [1080p] Extras Folder Soundtrack Folder The music library can or will scan the movie folders and the soundtrack folder within the movie folder then place and display those soundtracks into the music library correctly named with art, info, artist and so on. Thanks

I can reproduce this issue on a Philips TV with Titan OS (TPN246E). I tried the "Reinstall TV" solution mentioned above. After reinstalling the TV, Emby worked normally again. I could connect to my Emby server, select the user and use the app without any problems. However, as soon as I tried to exit Emby and the menu with options such as "Exit" and "Switch User" appeared, the app got stuck on this screen again. No matter which option is selected, nothing happens and it is no longer possible to leave this menu or use Emby. Power cycling the TV does not fix the issue. I also tried changing the Emby user's password, removing the TV from Devices on the Emby server and even disabling the user account. None of these had any effect. So "Reinstall TV" only fixes the issue temporarily. As soon as the exit menu is used again, the problem returns. TV firmware: TPN246E_V246.010.000.121 Build date: 2026-05-23 It seems that using the exit menu causes the Titan OS Emby app to get stuck in a persistent local state.

Ja kann ich bestätigen, ist mir auch schon aufgefallen, sowohl bei neu hinzugefügten Serien, wie auch bei den Filmen. Habe gerade nochmal geschau, der Letzte Film bei dem das Intro geladen wurde war am 19.07.26, der nächste am 24.07.26, und da wurde schon keines mehr geladen. Alle neuen Filme oder neuen Serien danach sind komplett ohne Themes/Intros. Ich nutze übrigens aktuell die Beta 4.10.0.31, falls das eine Rolle spielen sollte.

Guten Tag und schönen Sonntag wünsche ich allen. Habe seit einiger Zeit ein Problem wegen den Theme Plugins. Bei beiden Plugins, "Movie Theme Songs" und Movie Theme Videos" werden keine Treffer mehr erzielt. Hatte schon mit der EmbyServer Version 4.9.5.0 die letzte Zeit keine "theme.mp3" und keine "theme.mp4" / "theme.jpg" nun auch mit Version 4.10.0.40 keine Treffer. Kann das jemand bestätigen und das eventuell bitte gefixt werden ? Mit freundlichen Grüßen Anskar26 ---------------------------------------------------------------------------------------------------- Hello everyone, and I hope you're having a nice Sunday. I’ve been having an issue with the theme plugins for some time now. Neither of the plugins—"Movie Theme Songs" or "Movie Theme Videos"—is returning any results anymore. I wasn't getting any "theme.mp3", "theme.mp4", or "theme.jpg" files with Emby Server version 4.9.5.0 recently, and now I'm still getting no results with version 4.10.0.40. Can anyone confirm this, and could it please be fixed? Best regards, Anskar26

Ja kann ich bestätigen, ich antworte in dem anderen verlinkten Threa nocheinmal

Wait for what? Beta release has had all these features for the last 6 months.

When using the Windows desktop app I am not able to connect to a locally hosted server on the same subnet. The server is still accessible from the same machine in a web browser. I can't find a location for log files. The location of the application is apparently locked behind a Microsoft Store datastore. I really wish they would just release this as a normal windows application and not require the ridiculous MS store. How can I troubleshoot this connectivity issue?

This would be very useful although I might suggest an alternative approach using rate limit pools rather than global and live tv rate limits per user. This would allow finer-grained access controls based on the media source. Example: Pool ID: 1 Name: IPTV Fairness Limiter Included Libaries: Live TV, Movies Apply to Users: Joe Jimmy Stream Rate Limit: 2 Rate Limit Filter: [x] Device ID [ ] IP Address Pool ID: 2 Name: Shared Credential Limiter Included Libraries: All Apply to Users: Joe Stream Rate Limit: 1 Rate Limit Filter: [ ] Device ID [x] IP Address

Okay, you are running directly on the TV, right? Android in that context doesn't expose the different video modes so the settings aren't there.

As I said, I don't have dupes. Emby, for some unknown reason, thought I had dupes. But I never had dupes. I do have other libraries that were unaffected by this issue. So I can only assume that somehow the database for this particular library got corrupted somehow.

Well, if you do actually have dups and that setting is set to what I showed, then they will come back...

I never touched that particular setting. Was that something introduced recently in the latest update? I checked it and it was set to what it shows in your pic. So I assume that is the default setting. Anywho, in the end the only way to fix the problem was the to delete the entire library and recreate it. No more phantom duplicates.

There's no way for Emby to know whether you intentionally emptied out your library or if the share failed to mount properly and I don't think it should be up to Emby to figure out which it is. What I did to prevent this library purge you experienced was to add conditions to the [Unit] block of the Emby service file to prevent it from starting if shares aren't mounted. So if you're running Emby through a systemd service, this should help. This little guide assumes a Debian bare-metal install, so if you're running Emby on something else, your mileage may vary, but it should be similar on other Linux platforms running systemd. If you've never modified the Emby service file before, copy the default service provided by Emby to /etc/. cp /lib/systemd/system/emby-server.service /etc/systemd/system/emby-server.service Edit "/etc/systemd/system/emby-server.service" and add the following block under "[Unit]". Modify the lines to fit your setup. I run 3 shares in my setup, but if you only have one, you only need one of each "ConditionPath" conditions. RequiresMountsFor=/mnt/Animation /mnt/Movies "/mnt/TV Series" ConditionPathIsMountPoint=/mnt/Animation ConditionPathIsMountPoint=/mnt/Movies ConditionPathIsMountPoint=/mnt/TV Series ConditionPathExists=/mnt/Movies/.Movies.md5 ConditionPathExists=/mnt/Animation/86/.86.md5 ConditionPathExists=/mnt/TV Series/24/.24.md5 And remove the following line from the file. After=network.target Then run systemctl daemon-reload and that's it. "RequiresMountsFor" replaces the "After" condition and will start the service when these shares are mounted. However, if these mount points don't exist in fstab or in systemd's view as a whole, this condition passes without triggering any errors and starts the service, which is where the second condition `ConditionPathIsMountPoint` comes in just in case. And then we have a sentinel file on each share with `ConditionPathExists` to make sure the right share is mounted on the right path. That sentinel file can be any file inside the share that is always expected to be present. With this, Emby will fail to start whenever shares aren't mounted correctly and it would be up to you to investigate why before restarting the service manually. I believe that's a better outcome than what you had to deal with. Hope that helps.

This doesn't appear to be an issue. I changed the channel numbers and the excluded tag wasn't applied to the new channels

Please PM me details. Thx.

Persistent queue still doesn't exist even on a single device when the app is closed or user focus is switched to a different app for a short while. What's the status of this long-discussed basic functionality?

Persistent queue still doesn't exist even on a single device when the app is closed or user focus is switched to a different app for a short while. What's the status of this long-discussed basic functionality?

Just some background on why we are considering this: The configuration is complex and somewhat hidden. This alone tells us that the majority of people never discover it or use it and the new method will actually be a benefit for them because they will now go back to where they were before automatically instead of always going to "Suggestions" at the start. Again, the configuration for this (at least in all the other apps) is overly complex and muddled and we are moving towards the ability to customize exactly which tabs are available in each library which will complicate it even more. Returning to where you were before is a pretty common method of operation in most situations.