All Activity

hi, are you still having an issue with this?

ok if you open a command prompt and enter powercfg /requests then you can see what apps have a power lock open on the system.

@softworkz

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