All Activity

@softworkz

Hi, are you still seeing this with the latest update to Emby for iOS?

Is there a "quick and easy" way to pop up a notification dialog from the Plugin API (which is not using the PluginUi at this moment)?

Will this be available across all platforms such as Nvidia Shield, Google 4K streamer and so on?

The current root page of the dev documentation should have a "Plugin C# API" and "Server C# API" in its "Emby SDK" TOC on the left hand side. Right now, to find either API, you have to realized its under the developer home (not obvious), then find the "worth a look" link in the "Emby Server .NET API" group. It would be great if there was a quick link at the top to get to the "Documentation/reference/index.html" page Scott

Thanks! Thats what I "kindof" figured. As in the old way works, and is still supported. But the new way is better Is there any "this is what you did in js+html, this is the equivilent in the PluginUI" reference material?

It's still not working as I show at first place, it does working from tv guide. Are you going to fix that or not? depends on you.

I reckon it’s more a case of the user having to test it. They pay money for the app and/or a subscription, and on top of that they get to act as a guinea pig. And then they’re asked to kindly send in the log. That way, the programmer saves themselves the testing phase.

I can open an issue but as a workaround if you can add the option to the "Android" version to toggle passthrough of audio formats like the Android TV version, it wouldn't matter that auto detect doesn't work. Thoughts?

Clear answer: No, you won't have to do this. As for advantages and disadvantages, we don't have such a table. The new one is called Plugin UI: https://betadev.emby.media/doc/plugins/ui/index.html The old htmljs method is still supported and has no specific name. The general guidance is to always use Plugin UI unless you really need something that cannot be done with Plugin UI - which are things like having full control over the rendered UI, and showing images. Almost everything else - in the context of a settings UI can be done with Plugin UI just well. The advantages of Plugin UI are It's future proof many older plugins have a weird-looking UI these days when they haven't been updated whatever you may do today in a htmljs plugin UI can be broken shortly after due to general UI code changes it's easy and declarative You just define your settings as a C# class with appropriate interactions, you don't need to care about presentation You don't have to create your own API service for the htmljs client code to interact with the server You can stick to a single language for development (C#) For more, see here: https://betadev.emby.media/doc/plugins/ui/index.html

Hi, are you still having an issue with this?

Hi, yes that is something we are considering. Thanks.

HI, what metadata sources would you like us to incorporate?

HI, are you still seeing this with Emby for Android 3.5.49+ ?

Hi, has this helped?

I've moved this to feature requests. Thanks.

Yes — and in the same directory throughout. Everything in that session, the run that works and the runs that fail, writes to /var/lib/emby/transcoding-temp/04C768/. 04C768_220.ts is written there twice. First by the run that serves it: 14:51:48.772 ProcessRun 'StreamTranscode b8bdc3' Execute: ... -ss 00:20:54.000 ... -segment_start_number 209 14:51:48.901 Process exited with code 0 14:51:50.021 GET .../hls1/main/220.ts 14:51:50.064 Response 200. Time: 43ms. Content-Length: 2,169,708 That run wrote 209 through 220 in 129 ms and exited. Seventy seconds later, same index, same directory: 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 ... filename=04C768_220.ts 14:53:00.628 video:2332kB audio:148kB 14:53:00.634 Process exited with code 0 14:53:00.666 Response 500 So by the server's own account it is there, and it was written again on the way to the 500. What the log cannot tell me is whether the file survived on disk between 14:51:50 and 14:53:00, and I think that is the half your question actually turns on. I can't answer that from a log, but I can answer it with an ls: this reproduces on demand and the failing window is a comfortable 45 seconds of retries. Tell me what you want listed and I'll run it and paste the output raw. Two corrections while I'm here, both mine. The "File Deleted" line is a red herring and I should have checked it before it went near this thread. It is AppendExtraLogData removing its own graph file (ffmpeg-directstream-...graph.txt), and it appears identically on the run that served 200s. Nothing to do with segments. And I overstated something in my last post. I said segments 209-220 have no "Starting transcoding" line. The first request for 209 does: 14:51:48.762 GET .../209.ts 14:51:48.762 Starting transcoding because currentTranscodingIndex=null 14:51:48.772 ProcessRun 'StreamTranscode b8bdc3' Execute: ... 14:51:48.831 Response completed after client disconnected. Time: 69ms. 14:51:48.901 Process exited with code 0 14:51:48.930 GET .../209.ts (the player asks again) 14:51:48.997 Response 200. Time: 67ms. The excerpt I attached starts just after that, at 14:51:48.930. That was careless rather than deliberate, the full log has it, and I would rather point at it myself. It also makes the pattern cleaner than I had it, so it costs me nothing to fix. It is not that the working segments never start an ffmpeg. It is that no request which starts its own ffmpeg has ever come back with the segment: the first 209, then 221 nine times, then 220 nine times. 209 only succeeded because the player asked again and the file was already on disk by then. At the tail, asking again does not help — every retry starts another process, every process writes the file and exits 0, and every one of them still answers 500. I have re-attached the excerpt with those lines put back in. embyserver-excerpt-149368.txt

HI, how does the latest update to the app compare for you?

Hi, we'll take a look at this. Thanks.

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".