All Activity

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.

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

Thanks — I went to test that, and the result surprised me. If the list were approximating keyframe positions, changing the keyframe-break request ought to change it. It doesn't. Same file, same parameters, only BreakOnNonKeyFrames varying: BreakOnNonKeyFrames=True 222 segments, all #EXTINF:6.0000, sum 1332.000 (parameter absent) 222 segments, all #EXTINF:6.0000, sum 1332.000 BreakOnNonKeyFrames=False 222 segments, all #EXTINF:6.0000, sum 1332.000 The three playlists are byte-identical once the PlaySessionId is stripped. And the count is exactly ceil(declared duration / segment length), at both lengths I can get the server to produce: ceil(1326.336 / 6) = 222 -> 1332.000 s advertised ceil(1326.336 / 3) = 443 -> 1329.000 s advertised So the list isn't an imprecise estimate of where keyframes fall — it doesn't consult them at all, and every entry carries the nominal segment length rather than a measured one. That's why I don't think an import-time scan is what's missing here: making the last entry honest doesn't need keyframe positions, only the end of the media. And the gap isn't boundary rounding, it's 6.6 s — a whole segment. And the failure isn't confined to the predicted segment 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. It gets 500 nine times as well. One of those requests, end to end — 93 ms: 14:53:00.573 GET .../hls1/main/220.ts 14:53:00.614 ProcessRun 'StreamTranscode c2b692' Execute: ... -ss 00:22:00.000 ... -segment_start_number 220 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 14:53:00.666 Response 500 ffmpeg produced the segment — 136 frames, 6.72 s, 2.4 MB — and exited 0. The request was answered 500 anyway. So there is a second failure that a better prediction would not fix, and it is the one that makes this unrecoverable: the client cannot get out of it even by stepping back to a segment that exists. Possibly related, from that same line: SegmentComplete reports Index=220 with Start=0.000000 End=1325.365000 Duration=1325.365000 — the length of the whole episode, for a segment holding 6.72 s. The command line carries -segment_time_delta -00:22:00.000 together with -copyts -start_at_zero. If anything downstream checks the produced segment against an expected time, that bookkeeping wouldn't match. I don't know the code, so this is only a guess. The transcoding path is a third thing again: there hevc_vaapi exits 139 (SIGSEGV) five times in forty seconds, and the request is never answered at all. None of this needs the prediction to become exact. Even leaving it as it is, overshooting by one segment could end the stream rather than start an unbounded retry loop — which is what turns a third of a second of missing video into a session that never finishes.

Thanks.

It's not random. It literally goes by which one is scanned into the library first. I've spent many hours testing various combinations to get it working and now it finally does.

How are you closing the app?

This could be made more accurate by scanning the file for keyframe information during import. The problem is that this can take a long time, so that’s why this is a prediction.

No, I can get to them no problem. If I revert back to 4.9.3.0 everything starts to come back and work.

Are the media folders unreachable at that time?