No Video or Stutter at playback start (1 Viewer)

[RoChess]

I update LAV and MediaInfo as often as I can/want, so I'm on version v0.7.64 on MediaInfo and v0.59.1 on LAV.

These are both versions not available yet for MediaPortal if you rely on MePo/MPEI updates.

Of course the respective changelog might show that issues have been fixed that would not be a problem for you to begin with, but updating is extremly easy so I do it anyway.

No matter how easy LAV is, it is still not a very friendly codec. I found this out due to concurrent RDP usage. The HTPC in the livingroom is one of the best systems I have in my network, so for it to go unused on the extra power is a shame. So while the wife is watching her TV shows, I can use the spare power to do other stuff, such as development in Visual Studio for IMDb+.

Of course it is also an easy way to manage the collection itself, move files over, rename/etc. However once I switched from MPC-HC standalone filters to LAV I noticed a terrible side effect. The moment I would use the LAV codec inside concurrent RDP, then MediaPortal in the livingroom would start to skip/stutter/delay/etc. This was never a problem with MPC-HC, infact I could play the same video at a different point inside the RDP window without a problem.

As to the exact technical reasons, if it is the splitter, or the video codec, or the audio codec, I've stopped caring. The purpose of watching a video inside an RDP window is rediculous, as I can watch them directly via the SMB shares. Still it underlines the issues LAV codec can add.

And MediaPortal accesses the media (which then kicks in LAV splitter/codec) via multiple different means either direct for playback, or indirect for thumbnail generation, mediainfo, etc.

 

[adspence]

I upgraded to the latest LAV and Mediainfo, same problems persist. There are only two ways that I get things working seamlessly a) use the MS codecs not LAV, or b) use MyVideos not TVSeries. It's a pity, as not using LAV loses all the configuration flexibility one has with that, especially around bitstreaming and subtitles.

 

[RoChess]

Yes, LAV is not multi-thread friendly, which is were the problem originates from.

Solutions are to A) use a mult-thread friendly codec or B) limit the codec threads to just one.

The problem for B is that eventually you run out of options you can adjust or loose other features. For example you can disable thumbnail generations easy, but disabling MediaInfo kills other function that can be useful.

I did notice however that MediaInfo v1.5.0 goes about things really weird. When playback starts I see the MediaInfo handler is called 3x and that is rediculous imho. On my new HTPC I have found a small delay in some situations, but that is because the HDD holding the content has gone to sleep and needs time to spin back up again. Perhaps MP-TVSeries can be expanded to the point that when you enter a series that has content on a HDD that is asleep that it already tries to wake the drive up, so by the time you push play on the actual episode the drive is already 'ready'. @adspence, could it be that this is also a main reason for your delay? Especially a NAS going to sleep along with the MediaInfo delay, compounded with a non-multi-thread codec such as LAV can build up to extensive delays. There is already a plugin available that can wake a NAS up when you are using MediaPortal, so that could benefit you then if that is your situation.

I'm personally doing extensive testing with a Kill-A-Watt meter to see if there are any benefits to putting drives to sleep at all. From a lifetime perspective it has actually shown it might negativly impact lifespan if you stop/start drives a lot. My testing purpose is mainly for economical reasons on power bill (and to small extend noise). HDDs do have a low power usage, but when you have a ton of them inside a system it adds up quick, especially when you are like me and have HTPC running 24/7. Of course it will require me a full month of testing each scenario properly, and I have 5 scenarios to test, so I won't know the pro/cons for a long time.

 

[adspence]

Drive spin down is certainly a good point to investigate. I don't think that is my problem, but the content is actually an UnRAID. I'll see if keeping everything spun up for longer helps. Given this NAS has 9 drives I do like to keep those not in use spun down, as i definitely affects power usage otherwise, but then I'm only actively using it a few hours an evening, so maybe I can increase the spindown delay.

Do you happen to know which plugin deals with NAS, I can't spot it with a simply search. I see the WOL one, but my NAs doesn't sleep, only it's drives.

 

[RoChess]

The PowerScheduler++ plugin as it is now called with v1.5.0 can be configured to keep system from going 'idle', however not sure how that works for external unRAID server then, but you could open a thread on the WOL plugin one, see if they can add the function there as an additional option otherwise.

 

[adspence]

One question I forgot to ask is, why do we need to use MediaInfo 3 times? It only seems to be the last instance of the execution that takes ages. Is that the only point at which is tries to scan a chunk of the video file? What do the other time do, just read a header?

WOL isn't going to help me here as it is the disks on the UnRAID that spin down, I don't make the server sleep. Anyway, the file is most certainly on a drive that is already spun up or all the other mediainfo executions would also take ages to do anything as the drive spins up. If this is about the files not being local and on a server then there is nothing I can do about that. It is a GigE network, and the server and drives are certainly fast enough to cope with kind of data rates for these files.

For now it seems that I'm going to have to live without LAV or without MediaInfo

 

[adspence]

Just realised that living without mediainfo isn't possible. Imports won't work. Ho hum.

 

[adspence]

I have just done a reinstall of everything and an import in the MP-TVseries config of >500 videos. Each took between 8-10s for the medainfo scan step. So if something similar happens each time one plays a file then no wonder there is a problem here.

If the only solution is to ditch LAV because of concurrency issues then what is the filter of choice, and most especially the splitter that people would use instead?

It is strange that I've been much the same set of client and NAS server hardware for years. Mediaportal and TVSeries has been fine up until the last couple of months, so maybe something has changed in recent releases of these (or Mediainfo). If I was able to disable the final MediaInfo scan of the 3 that appear then that might help esp. if that is only used to deal with screen refresh rate sync, which I don't currently need.

At present I'm sticking with MyVideos as that still seems to be behaving itself.

 

[RoChess]

MPC-BE standalone splitter/codec would be the choice. It is driven by the main developer on MPC-HC who was unstatisfied, and probably why MPC-HC now uses LAV as well.

Even on a 64-bit OS you need 32-bit codec, due to MediaPortal being 32-bit.

Direct link to MPC-BE standalone solution at SourceForge == http://tinyurl.com/mpc-be-codec

 

[adspence]

many thanks. I'll take a look at this.