All Activity

Not sure what you mean, to me it looks like the two are treated equally:

I see the confusion, Im taling the Emby.SDK/Documentation/index.html The home page for emby dev documenation, should have a one click way to go to the C# api, just as it does the REST API Clients

Understood — I'll test the next one the same way. Two things I measured in the meantime, in case either is useful before you cut it. THE JUMP THRESHOLD — YOUR LOG PRINTS IT I said the tail fails "after a seek", which is too broad. On 4.10.0.29, in a throwaway container with a synthetic 30-minute MKV, your own log says: 6-second segments: "segmentGap is 19 and max allowed gap is 4. requestedIndex=31" 3-second segments: "segmentGap is 11 and max allowed gap is 8. requestedIndex=16" 4 × 6 = 24, and 8 × 3 = 24 — the limit is 24 seconds of media whatever the segment length. Either side of it, with 3-second segments: jump +5 -> 200 after 19.8 s no restart: it attaches to the running transcode and waits jump +9 -> 200 after 31.1 s no restart jump +12 -> 200 after 5.6 s one restart So a short jump costs nothing; it is only when the jump forces a restart that the tail is a problem. Which is also why resuming an episode is enough to hit it — resume, chapter start and scrub are the same thing here, and all three are well past 24 seconds. If it helps you reproduce: on an idle machine the same request failed 10 times out of 16, and with two other transcodes running alongside it, 0 out of 16. YOUR QUESTION ABOUT THE TRANSCODE TEMP DIRECTORY You asked a while back whether the segment was in the transcode temp directory. Sampling it every 10 ms through a request that ends in 500: t+0.085 s ..._300.ts.tmp (0 bytes) t+0.171 s ..._300.ts (1,060,320 bytes) complete, named as your ffmpeg logs it t+0.215 s <- the response: 500 The file is on disk 44 ms before the 500 goes out. A second later: 10:58:51.721 EncodingManager: Deleting temp folder /config/transcoding-temp/8AA322 DirectoryNotFoundException: Could not find a part of the path '.../8AA322/...' which is why retries after that point answer 404. So the answer is: it is there, and then it isn't. No mechanism from me — I have offered three and measured all three dead. This is just what the server does, in its own words.

Hi, my guess would be that the chromecast receiver can't reach your emby server. if you can provide a log from the app then that will help us confirm that. Thanks.

Hi, can you please show a screenshot example? Thanks.

Just started using the Emby LG app and it's absolutely great. Almost perfect and I think better then the android app. My only issue is that there are a few rows of darker pixels (around 10 or so I would guess) at the top and bottom of every video. Almost like the brightness has been turned down in these areas. Does anyone else have this? Is there a fix? Thanks

It's already there. When you click on REFERENCE at the top, you get two choices in the TOC: https://betadev.emby.media/reference/index.html

Thanks. thats kind of what I figured. Are there any plans to recreate the "Dashboard" class API for the server side (not just the JS system)?

Sound good. Meanwhile I'll test other apps and see how they behave. (Retired IT guy here).

OK we'll take a look at it. Thanks. But by the way on the Shield you can bypass Emby Server's embedded SMB support and mount the SMB path to a local path on the Shield. Then use the local path in Emby Server instead of the SMB path. You might also be able to do this with the WD but I'm not sure.

It still seems to be working, though it's not clear to me why! Sorry, forgot to come back and mark resolved.

the best you can do is send a remote control command to a session to display a message.

@ramseynhas this helped?

Let us know how that goes. Thanks.

Sorry if I was confusing My goal? I want to be able to get to the server side C# api documentation as soon as possible. Not the REST api I was hoping it could be added to the tree explicitly on the LHS

Learning the proper terms. From a plugin, running on the server side, but a plugin that is not running the new PluginUI architecture

Resume still works; I’ve tested it myself on my Shield in the bedroom using the app – but ‘skip intro’ won’t work any more. That’s something you could live with, though, if the player plays back the track properly. That’s my opinion.

Haven't tested yet, but will I loose the "resume etc" that is in the original player? I'll remember to adjust refresh rate.

It should be for every video in the queue but @speechlescan elaborate more on what the roku app is looking for.

Just checking in, from my current test I can not find any issues and everything works as expected

Do we have an update as I believe the test version has expired now. I have had no issues, other than we need support for more systems of cours

It appears to be a server issue rather than an app issue, as it's also happening on the Windows app.

Works fine for me.

OK. I'm confused. I still don't know what triggers it. It randomly shows up about once every 10 to 15 videos that have played in the queue. This is in folder view, random play selected. If it's not supposed to happen that's fine. Just figured it was a feature and trying to figure out how to utilize it. Thanks.

So, when using dynamic mode, it appears requests are not being done each time entering a given screen. So, I have a dynamic node to tv shows, and, I am showing the latest unwatched episodes. What happens is if I start Kodi, they all appear. Now, a new show gets recorded in Emby, and, I go back to show all unwatched episodes, and, it's not there. So, dynamic is working as static for me. I can restart Kodi and it's there. It just never seems to go back and get the new list when entering a screen. Is there something I am missing, an option somewhere?