Call for tester for 1.4.0 features and fixes (4 Viewers)
- Thread starter Scythe42
- Start date
- Status
- December 18, 2012
- 238
- 73
- Home Country
-
Germany
Hello
with this build I and 2 other computers with AMD graphics cards do not have DXVA, which means you probably said to LIVE TV, a CPU utilization normally from 20 to 35% are there 5 to 10%, we use the LAV or Arcsoft codec, you can do that problem solving? anyway good job and thanks
with this build I and 2 other computers with AMD graphics cards do not have DXVA, which means you probably said to LIVE TV, a CPU utilization normally from 20 to 35% are there 5 to 10%, we use the LAV or Arcsoft codec, you can do that problem solving? anyway good job and thanks
Last edited by a moderator:
- Thread starter
- #143
This build doesn't change anything how filters work and how they utilize the GPU for decoding. At least I need some system specs to have a slight idea what might be causing this for you.
Und du kannst auch auf Deutsch schreiben. Besser als Google Translate Englisch...
Und du kannst auch auf Deutsch schreiben. Besser als Google Translate Englisch...
Last edited:
- Thread starter
- #144
Creating a new test build during the week for identifying what's happening on @infinite.loop's system.
It will focus on more log entries for slow startup as well as finding out why the RR changer still steals focus for him.
It will focus on more log entries for slow startup as well as finding out why the RR changer still steals focus for him.
Last edited:
- Thread starter
- #146
I'll give the following a shot:
I will use the BackgroundWorker class for all plugin loading. They can at least be loaded in parallel. That doesn't solve iloop's problem (which isn't a general one) that starting up plugins on his setup takes forever by my standards, but it should increase startup time in general for everyone.
Without too much work that should do the trick as it is still a conservative approach that only involves PluginManager.cs and not what's inside the individual plugins.
It should solve the delay in startup on iloop's machine.
The long delay where nothing is happening (he sees a black screen, as MP cannot render yet) is one of the plugins doing things and preventing MP from rendering (no log entries). That is a separate thingy that needs investigation afterwards. We'll then see to where it leads.
One thing I can't do is having MP let run on Basic Home for example and then wait until a plugin is ready if it is accessed. The current code is not ready out for this out of the box. Not really interested in changing this as start/stop of MP shouldn't happen that often like a normal movie player.
You minimize it to the tray and be done with it, if you want to do something else on your machine. At least with this test build...
Report back when I finished my threading experiments...
I will use the BackgroundWorker class for all plugin loading. They can at least be loaded in parallel. That doesn't solve iloop's problem (which isn't a general one) that starting up plugins on his setup takes forever by my standards, but it should increase startup time in general for everyone.
- Load everything over worker threads. Wait until all loading is completed and proceed with start
- Starting all plugins over worker threads. Wait until all starting is completed before continuing.
- Next step: loading and starting happens in parallel. Means every plugin gets loaded and started on its own. I probably crash MP here...
- And of course I close them all in parallel and wait before continuing as well if starting works out
Without too much work that should do the trick as it is still a conservative approach that only involves PluginManager.cs and not what's inside the individual plugins.
It should solve the delay in startup on iloop's machine.
The long delay where nothing is happening (he sees a black screen, as MP cannot render yet) is one of the plugins doing things and preventing MP from rendering (no log entries). That is a separate thingy that needs investigation afterwards. We'll then see to where it leads.
One thing I can't do is having MP let run on Basic Home for example and then wait until a plugin is ready if it is accessed. The current code is not ready out for this out of the box. Not really interested in changing this as start/stop of MP shouldn't happen that often like a normal movie player.
You minimize it to the tray and be done with it, if you want to do something else on your machine. At least with this test build...
Report back when I finished my threading experiments...
- Thread starter
- #147
Für jeden Support Case immer System Specs. Am besten direkt in deinem Profil ausfüllen, dann kann man nachgucken was du benutzt, wenn man dazu informationen brauch. Muss man nicht in diversen Threads suchen. Ist genau dafür gedacht.Ok was brauchst du von mir ?
Bei Playback Problemen hilft natürlich auch ein DirectShow Graph mit den Property Pages um zu sehen wie alles läuft (da gibt es Werkzeuge zu um das während des Playbacks abzufragen). Sollte auch irgendwo im Wiki stehen und im Forum so wie so. Einfach mal suchen, hab gerade keinen Link zur Hand.
Last edited:
- Thread starter
- #150
Efforts so far.
Logging is a still a bit ugly though including types, I know... That is the last thing I need to update. It's just for debugging at the moment.
But looks good for my first try in threading on C#.
I abandoned te BackgroundWorker class as its only benefit is reporting events back to the GUI. Not needed here as there is no progress bar support in the Splash Screen anyway. Nah, not going to add it. Wasted time. It too long on screen anyway. Not going to enhance it.
Loading starts right away, and #1 finishes while #2 is still doing stuff. At least it it seems not to be sequential anymore. Guess I need to install a bunch of plugins. I want to see different start and finish orders to make sure nothing else is blocking stuff. Let's throw in a couple of them with some databases in. The nastier the better.
Code:
Start Loading #1
2013-01-27 17:49:56.762695 [Info.][(9)]: PulginManager: Start loading plugin 'C:\Program Files (x86)\Team MediaPortal\MediaPortal\Plugins\process\PowerSchedulerClientPlugin.dll'
Start Loading #2
2013-01-27 17:49:56.763671 [Info.][(10)]: PulginManager: Start loading plugin 'C:\Program Files (x86)\Team MediaPortal\MediaPortal\Plugins\process\ProcessPlugins.dll'
Finished Loading #1
2013-01-27 17:49:56.764648 [Info.][(9)]: PulginManager: Finished loading plugin 'C:\Program Files (x86)\Team MediaPortal\MediaPortal\Plugins\process\PowerSchedulerClientPlugin.dll'
#2 Does whatever additional stuff. Need to drill down through the code for a nicer logging.
2013-01-27 17:49:56.765625 [Info.][(10)]: Load plugins from: C:\Program Files (x86)\Team MediaPortal\MediaPortal\Plugins\process\ProcessPlugins.dll
2013-01-27 17:49:56.767578 [Info.][(10)]: File Version: 1.2.200.0
Finished Loading #2
2013-01-27 17:49:56.776367 [Info.][(10)]: PulginManager: Finished loading plugin 'C:\Program Files (x86)\Team MediaPortal\MediaPortal\Plugins\process\ProcessPlugins.dll'Logging is a still a bit ugly though including types, I know... That is the last thing I need to update. It's just for debugging at the moment.
But looks good for my first try in threading on C#.
I abandoned te BackgroundWorker class as its only benefit is reporting events back to the GUI. Not needed here as there is no progress bar support in the Splash Screen anyway. Nah, not going to add it. Wasted time. It too long on screen anyway. Not going to enhance it.
Loading starts right away, and #1 finishes while #2 is still doing stuff. At least it it seems not to be sequential anymore. Guess I need to install a bunch of plugins. I want to see different start and finish orders to make sure nothing else is blocking stuff. Let's throw in a couple of them with some databases in. The nastier the better.
Last edited:
- Status