All Activity

Not sure what to call each system, but html + JS is what I am calling when you define and return a list of PluginPageInfo in a GetPages method in your plugin. The "ControllerBase" system is when you return a list of IPluginUIPageController from UIPageControllers. Is there a table or listing to show the advantages and disadvantages of each? My primary question, is if I modify the c# code that builds the page in the "ControllerBase" system, will I still have to use chrome in debug mode and clear the cache and reload like I have to with the html+js system?

Works peachy for me, though I'd still like to see: albeit it's by no means a "must-have".

How’s the TV show status holding up? Are there any further tweaks needed?

Just the main HomeScreen After a movie finishes it goes back to the HomeScreen. I wake up in the morning and it is sat on that screen all night, both monitor displaying and pc on

is the 220 segment in the transcode temp directory?

Hi there, please attach the Emby server log from when the problem occurred: How to Report a Problem Thanks!

Attached: an annotated excerpt of embyserver.txt from that session. I trimmed it to the one failing playback plus one contrasting session, and collapsed the repeated 500s; the header says exactly what was cut. The full untouched log and the ffmpeg logs are yours whenever you want them. Two things in it are worth your time. 1) THE 500 IS NOT ABOUT THE MISSING SEGMENT 221 is the phantom the arithmetic promises. When the player doesn't get 221, it steps back to 220. That one is not predicted: it is real, it is inside the media, and it had already been served 200 earlier in the same session — 14:51:50, Content-Length 2,169,708, in 43 ms. It gets 500 nine times as well. Eighteen 500s in total, and then the server times the session out itself. 2) THE SERVER REPORTS "ERROR STARTING FFMPEG" FOR AN FFMPEG THAT RAN AND EXITED 0 The whole of that request for 220, in 93 milliseconds: 14:53:00.573 GET .../hls1/main/220.ts 14:53:00.614 ProcessRun 'StreamTranscode c2b692' Execute: ... -ss 00:22:00.000 ... 14:53:00.628 SegmentComplete=video:0 Index=220 ... Frames=136 filename=04C768_220.ts 14:53:00.628 video:2332kB audio:148kB subtitle:0kB other streams:0kB 14:53:00.628 EXIT 14:53:00.634 ProcessRun 'StreamTranscode c2b692' Process exited with code 0 14:53:00.666 Error processing request FfRunException: Error starting ffmpeg at BaseStreamingService.StartFfMpeg(...) at DynamicHlsService.GetDynamicSegment(...) 14:53:00.666 Response 500 The process started, wrote 136 frames / 6.72 s / 2,332 kB, and exited cleanly twenty milliseconds after it was launched — and StartFfMpeg threw "Error starting ffmpeg" over it. The ffmpeg output quoted inside your own error report is the evidence against the error report. One observation, offered as an observation and not a diagnosis. In this log the segments that work and the segments that 500 differ in exactly one respect. Segments 209 through 220 were all served out of a single ffmpeg that was already running — none of them has a "Starting transcoding" line. Every request that 500s is one where "Starting transcoding because currentTranscodingIndex=null" launched a fresh process, and that process, with only the tail of the file left to write, finished in 18–20 ms. All of those exit 0, and all of those answer 500. If whatever StartFfMpeg waits on assumes the process is still alive by the time it looks, a run that short would fail that check no matter how well it went. Easy to falsify from your side, and I haven't tried to guess further than the log goes. Why this matters beyond the arithmetic: if the playlist were clamped to the real end of the media tomorrow, this second failure would still be here — and it is the one that leaves a client with nowhere to go, because it cannot recover by falling back to a segment that does exist. One correction to my own post while I'm here. I said segment 221 is never written. On this run it is: ffmpeg is launched with -ss 00:22:06.000 -noaccurate_seek, which lands back on the keyframe at 22:00, so it writes a 221.ts holding the same 136 frames that 220 already holds. It still answers 500. The playlist entry still has no media of its own behind it — but I was wrong about the file. The end of the excerpt has the same episode played by Emby Web with 3-second segments, where the list runs to 442 — ceil(1326.336 / 3) = 443. The last index isn't served there either; that one dies with ffmpeg exit code 139, five times in a row. A small note on the cheap half of this, since the objection to fixing the list was the cost of scanning. Both of these are arithmetic on the runtime you already have, and neither needs to know where a keyframe falls: whole = declared_duration / segment_length (integer division) remainder = declared_duration % segment_length For this file, 221 whole segments and a remainder of 0.336 s. * Give the last #EXTINF that remainder instead of a flat 6.0000. The playlist would promise 1326.336 s instead of 1332.000 — the overshoot drops from 6.635 s to 0.971 s — and #EXT-X-TARGETDURATION:7 would stop contradicting 222 lines that all say 6. * If the remainder is below some minimum, don't emit that entry at all. Here 0.336 s is well under any sane floor, so the list would end at 220 and the player would never ask for 221, never step back to 220, and never meet either failure. The first on its own only makes the manifest honest — 221 would still be promised and would still 500. It is the second that removes the symptom. Happy to run anything you want run. embyserver-excerpt-149368.txt

I didn't have this issue until I updated. No settings changed on my end, just updated. I wonder if tests are being done across multiple devices before an updated release. I'll probably just roll back to the version that was working for me.

Hi, there's multiple options available but in order to suggest one we need to first understand what the exact issue is. Thanks.

HI there, can you please provide a specific example? How to Report a Problem Thanks !

Hi, what's on the screen in the emby app when this happens?

Glad to hear its working as expected!

@PatrickStarwhat exactly do you see in Emby? What exactly would you like fixed? Thanks.

awesome!! If you need or want logs and stuff from the media server pc, let me know and i will provide them

3.5.51 Core UI Update Only Core UI Changes from 26.0.15 to 26.0.17 Fix add to collection option missing for artists and albums Fix focus regressions with view transitions

Emby for Android 3.5.51 Released Changes 3.5.51 Core UI Update Only Core UI Changes from 26.0.15 to 26.0.17 Fix add to collection option missing for artists and albums Fix focus regressions with view transitions

I think this is already resolved in the upcoming 4.10 server release so just fyi, I don't think you need to spin your wheels on it.

No, it has happened before in the 4.x versions, when I have had to recreate the database because of different reasons, like a disk that failed and once a bad kernel I was experimenting with updating in the server pc, plus there are other services running on that same machine.

OK I wouldn't do that. You're saying this was a one-time problem then?

i will try, but it might take a very long time because of the size of my anime, movies, shows, and music. I will have to delete the database and recreate it like a fresh install to see if it happens again.

Hi there, please attach the Emby server log from when the problem occurred: How to Report a Problem Thanks!

26.0.17 Fix add to collection option missing for artists and albums

Emby Web App Update: Version 26.0.17 The Emby Web app has been updated to version 26.0.17 Go and try out: https://app.emby.media/ Changes 26.0.17 Fix add to collection option missing for artists and albums

Hi, are you able to get the issue to happen again?

Emby 4.9.x – Collections temporarily missing / missing artwork after library refresh, eventually repopulate after forced image refresh I wanted to document an issue I ran into with Collections on Emby 4.9.x in case it helps anyone else or provides useful information for the developers. Server Emby Server 4.9.x Native Linux installation Linux Mint Large movie library (2,000+ movies) Automatic collections enabled Minimum automatic collection size: 2 movies TheMovieDb enabled A small number of additional dynamic/curated collections managed by the ACdb.tv plugin Symptoms I initially noticed that a large number of collection posters were missing. The collections themselves were visible, but many had blank artwork. Refreshing an individual collection using: Collections → Collection → Refresh Metadata with: Replace images: Enabled Video preview replacement was also enabled during the first test caused the collection image to appear correctly. I then selected the collections in bulk and ran the same metadata refresh with Replace images enabled. This successfully restored the collection artwork. However, shortly afterward I noticed what appeared to be a second problem: the number of visible collections seemed much lower than expected. I remembered having roughly 350 collections, but at one point only around 140 appeared to be visible. For example: 30 Days of Night Collection was not visible even though both: 30 Days of Night (2007) 30 Days of Night: Dark Days (2010) were present in the library. Refreshing those two movies did not immediately recreate or reveal the collection. Database investigation Before modifying anything, I checked library.db. The supposedly missing collection was still present: Id type Name Path ParentId ProviderIds ------ ---- --------------------------- ---- -------- ----------- 218205 9 30 Days of Night Collection Tmdb=91660 The movie-to-collection links were also intact: LinkType ItemId ItemName LinkedId LinkedName -------- ------ --------------------------- -------- --------------------------- 6 134238 30 Days of Night 218205 30 Days of Night Collection 6 134242 30 Days of Night: Dark Days 218205 30 Days of Night Collection Both movies also still had their imported collection information: ItemId Name ProviderIds ------ --------------------------- ----------- 134238 30 Days of Night Collection Tmdb=91660 134242 30 Days of Night Collection Tmdb=91660 The collection count in the database eventually showed: CollectionsInDatabase --------------------- 333 So the collection records had apparently not actually been lost. TMDb activity The Emby log showed the server actively requesting collection metadata/images from TMDb and receiving HTTP 200 responses. Example, with the API key removed: Info HttpClient: GET https://api.themoviedb.org/3/collection/9380?api_key=[REDACTED]&append_to_response=images&language=en-US&include_image_language=en-US,null Info HttpClient: Http response 200 from https://api.themoviedb.org/3/collection/9380?... after 46ms Info HttpClient: GET https://api.themoviedb.org/3/collection/98036?api_key=[REDACTED]&append_to_response=images&language=en-US&include_image_language=en-US,null Info HttpClient: Http response 200 from https://api.themoviedb.org/3/collection/98036?... after 50ms There were many requests like this occurring one after another. What ultimately happened After the bulk collection refresh with Replace images enabled, the collections and their artwork began appearing gradually. Refreshing the Collections page periodically showed more and more collections. Eventually the visible number rose to approximately the same number of collection objects present in the database. The ACdb-managed collections also began appearing normally again without changing the ACdb configuration. Working procedure What worked for me was: Open Collections from the normal Emby user interface. Select the affected collections, or bulk-select all collections. Choose Refresh Metadata. Enable Replace images. Start the refresh. Allow Emby to continue processing. Do not immediately assume missing collections have been deleted. Refresh the Collections page periodically and allow time for the entries/images to repopulate. In my case, collections appeared gradually while Emby continued downloading collection metadata and artwork. Possible 4.9.x issue What was confusing is that the UI initially made it look as though a large portion of the collections had disappeared, even though: The collection objects still existed in MediaItems Their TMDb IDs were still present Movie-to-collection links in ItemLinks2 were intact ImportedCollections still contained the correct collection information TMDb requests were succeeding with HTTP 200 responses This makes me wonder whether there is an issue in 4.9.x involving collection metadata/image refreshes, cache invalidation, asynchronous collection rebuilding, or how the Collections view is updated while a large refresh is still running. It may also be useful if the UI could indicate that collection metadata/artwork is still being processed, because during a large refresh it can look as though collections have actually been removed. No direct database modifications were required to resolve the issue. Hopefully this information and the database/log details are useful for tracking down any remaining Collections-related issues in the 4.9.x releases. I hope this helps somehow; I've had this issue multiple times during the 4.9.x versions; I just had not been able to do anything with it for health issues. I will also add that the investigation and troubleshooting were with ChatGPT's aid. Got to put it to work in something useful and not just make cat girl pics and videos lol. embyserver.txt