MP 1.2.3 won't install -- this has to be a mistake, right? (1 Viewer)

[cewillis]

Any particular codec recommendation?

Try the LAVFilters. You can install them with the MediaPortal Extension Installer.

I would, but as we discussed in https://forum.team-mediaportal.com/threads/mpei-broken-on-my-installation.109673/ , MPEI isn't working for me.
(why isn't the link icon available in this reply????? -- it's 'greyed' out)
I'll look for another way to install the LAV filters.

Could you describe your setup in a bit more detail - gear and connections, but also power states (like if you have a receiver, is it always on, and/or does it get powered on before the HTPC resumes).
If you haven't installed the LAV filters already, could you please also grab us some logs showing a "working properly" scenario - sometimes being able to compare and contrast helps to isolate the problem.

mm

Setup (didn't this used to be included at the beginning of any support request thread?)
MediaPortal Version: 1.1.0.0
MediaPortal Skin: Blue3
Windows Version: Xp Sp3 + many, many Windows 'updates'. (even though logs say Update: NEVER)
CPU Type: Intel Core I3
HDD: WD 1 TB
Memory: 4 GB
Motherboard: Intel DH57DD
Video Card: none -- on chip
Video Card Driver: Intel
Sound Card: on MB
Sound Card AC3:
Sound Card Driver: Intel
1. TV Card: Hauppauge HVR 2250
1. TV Card Type: Dual Hybrid
1. TV Card Driver: Hauppauge
MPEG2 Video Codec: see image in above post
MPEG2 Audio Codec: "
h.264 Video Codec: "
Satelite/CableTV Provider: Western Broadband analog/digital cable (small time local operator)
HTPC Case: nMedia 1080P
Cooling: case and PS fan
Power Supply: Antec 450 (old spare)
Remote: HAMA clone - USB infrared
TV: Sony 46 LCD
TV - HTPC Connection: HDMI
This is everything that is in my setup right now. Analog/digital cable connected to Hauppauge HVR 2250, HTPC connected to TV by HDMI. No satellite or audio receiver.
Don't know what else I can say about the setup: it's deliberately 'as simple as possible - but not simpler.' (favorite Einstein quote)
The TV is 'always' on before manually waking up the HTPC. (I seriously doubt it's ever different, but can't swear it)
There are two cases when the HTPC wakes up when the TV is off.
One case is the HTPC reboots every morning at 5:00 am by scheduled task. Right after that, it 'fixes' the database if needed, and downloads tv guide data for xmltv.
The other case is the HTPC often wakes up to record tv shows when the tv is off.

I'll get the 'working properly' logs ASAP - no later than tomorrow morning.

Thanks gentlemen.

 

[mm1352000]

Cheers for the detail.

You've probably found this already, but for posterity... the LAV filters can be found here:
http://code.google.com/p/lavfilters/downloads/list

(why isn't the link icon available in this reply????? -- it's 'greyed' out)

For me it only works when I select text - otherwise it is disabled. URLs are automatically recognised and "linkified" when you paste them in.

This is everything that is in my setup right now. Analog/digital cable connected to Hauppauge HVR 2250, HTPC connected to TV by HDMI. No satellite or audio receiver.

Hmmm. I wouldn't have thought too much could go wrong with that. I'm puzzled. Lets hope that comparing logs can shed some light on the situation.

mm

 

[cewillis]

Logs attached. Obtained just after starting a playback that was working fine by stopping MP and TV via Task Manager while playback in progress.
Yes, found the LAV filters, but will wait to install.
Many thanks again.

 

[mm1352000]

Hi again Cal

Well, those logs are definitely helpful.
When I look at the bit where the codecs are getting connected between TsReader and the renderers (very loosely speaking: hooking up the file to the display and speakers) everything seems to be fine:

[collapse]2012-07-25 20:01:30.296875 [Info.][MPMain(1)]: VMR9: added Video Mixing Renderer 9 to graph
2012-07-25 20:01:30.312500 [Debug][MPMain(1)]: VMR9: SetDeinterlacePrefs()
2012-07-25 20:01:30.312500 [Debug][MPMain(1)]: VMR9: Enabled YUV mixing - No DX Error
2012-07-25 20:01:30.312500 [Debug][MPMain(1)]: VRM9: Turning on nonsquare mixing - No DX Error
2012-07-25 20:01:30.312500 [Debug][MPMain(1)]: VRM9: Set filter mode - None No DX Error
2012-07-25 20:01:30.312500 [Debug][MPMain(1)]: VMR9: Now active
2012-07-25 20:01:30.312500 [Debug][MPMain(1)]: VMR9: Renderer successfully added
2012-07-25 20:01:30.328125 [Info.][MPMain(1)]: Added filter: MPC - MPEG-2 Video Decoder (Gabest) to graph
2012-07-25 20:01:30.328125 [Info.][MPMain(1)]: Added filter: MPC - MPA Decoder Filter to graph
2012-07-25 20:01:30.328125 [Info.][MPMain(1)]: TSReaderPlayer: Render TsReader outputs
2012-07-25 20:01:30.328125 [Debug][MPMain(1)]: Filter: TsReader - try to connect: Audio
2012-07-25 20:01:30.328125 [Debug][MPMain(1)]: PlaneScene: PresentImage() dispose surfaces
2012-07-25 20:01:30.328125 [Debug][MPMain(1)]: PlaneScene: PresentImage() dispose surfaces
2012-07-25 20:01:30.328125 [Debug][MPMain(1)]: PlaneScene: PresentImage() dispose surfaces
2012-07-25 20:01:30.328125 [Debug][MPMain(1)]: PlaneScene: PresentImage() dispose surfaces
2012-07-25 20:01:30.343750 [Debug][MPMain(1)]: Filter: TsReader - try to connect: Video
2012-07-25 20:01:30.343750 [Debug][MPMain(1)]: PlaneScene: PresentImage() dispose surfaces
2012-07-25 20:01:30.359375 [Debug][MPMain(1)]: Filter: TsReader - try to connect: Subtitle
2012-07-25 20:01:30.359375 [Debug][MPMain(1)]: - failed
2012-07-25 20:01:30.359375 [Debug][MPMain(1)]: Check graph connections for: Video Mixing Renderer 9
2012-07-25 20:01:30.359375 [Debug][MPMain(1)]: Check graph connections for: DirectSound: Intel(R) Display Audio Output 1
2012-07-25 20:01:30.359375 [Debug][MPMain(1)]: Check graph connections for: MPC - MPEG-2 Video Decoder (Gabest)
2012-07-25 20:01:30.359375 [Debug][MPMain(1)]: Check graph connections for: MPC - MPA Decoder Filter
2012-07-25 20:01:30.359375 [Debug][MPMain(1)]: Check graph connections for: TsReader[/collapse]

Compare that to the extract that I posted earlier and hopefully the differences are clear - no "failed" message for the audio codec (you can safely ignore the subtitle failed message - that is just saying there are no subtitles in the stream), and no "removing..." message.

So based on that it seems like the problem might be related to codecs or TsReader.

When I compare the TsReader logs I see...

(working)
[collapse]25-07-2012 20:01:30.328 [7e8]aud:CompleteConnect()
25-07-2012 20:01:30.328 [7e8]aud:CompleteConnect() done
25-07-2012 20:01:30.343 [7e8]vid:CompleteConnect() done
25-07-2012 20:01:30.375 [7e8]CTsReaderFilter:ause() - IsTimeShifting = 0 - state = 0
25-07-2012 20:01:30.375 [e20]aud:OnThreadStartPlay(0.000000) 1.00
25-07-2012 20:01:30.375 [14c]vid:OnThreadStartPlay(0.000000) 1.00 0
25-07-2012 20:01:30.375 [7e8]CTsReaderFilter:ause() - END - state = 1
25-07-2012 20:01:30.375 [148]CTsReaderFilter::ThreadProc start()
25-07-2012 20:01:30.375 [7e8]filt:IID_IMediaSeeking()[/collapse]

(not working)
[collapse]17-02-2012 12:19:13.484 [150]aud:CompleteConnect()
17-02-2012 12:19:13.484 [150]aud:CompleteConnect() done
17-02-2012 12:19:13.500 [150]vid:CompleteConnect() done
17-02-2012 12:19:13.515 [150]CTsReaderFilter:ause() - IsTimeShifting = 0 - state = 0
17-02-2012 12:19:13.515 [e60]vid:OnThreadStartPlay(0.000000) 1.00 0
17-02-2012 12:19:13.515 [150]CTsReaderFilter:ause() - END - state = 1
17-02-2012 12:19:13.515 [ee4]CTsReaderFilter::ThreadProc start()
17-02-2012 12:19:13.515 [150]filt:IID_IMediaSeeking()[/collapse]

Note there is no "aud:OnThreadStartPlay...", meaning the audio is not starting... which could be due to the codec not being able to be connected. This seems to support my theory.

When I say it could be a problem with codecs, I mean that the codec may not be able to handle the encoding format and options that your provider uses perfectly. That being the case, it might be expected that you would have more consistent problems with some recordings and even issues with live TV. Since you haven't reported those symptoms, I'm leaning more towards TsReader issues.

Assuming that my theory is correct (and I would hope that is a reasonable assumption), lets step away from all the technical jargon and try to answer your original question:

I would really appreciate it if someone knowledgeable could tell me if the problem is fixed (for sure!) in a later version of MP.

First, I want to be really clear: I can't guarantee anything, and probably nobody else can either. That really is like the impossible question from a developers perspective.
That aside, my recommendation to you would be:
1. Try the LAV codecs (and other codecs like FFDShow if you like).
2. If the codecs don't solve the problem, update to MP 1.2.3.

I'm not a codec expert but as I said previously those MPC codecs that came with MP 1.1.x are now quite outdated. The LAV codecs can decode additional formats and variations that the MPC codecs can't. My experience is similar to what many other people on this forum have reported - they seem generally more reliable. They're definitely worth a try.

I'm also not the expert on TsReader but I do know that TsReader has received significant attention from Tony (Owlsroost) and others since MP 1.1.x. There is a reasonable chance that if the problem is in TsReader then it will have been fixed.

Obviously upgrading risks breaking what is working, but there are also rewards - new features, bug fixes and significantly better support. I recommend the update not only because it is our standard practice for reporting issues but also because I genuinely believe that it would be better to upgrade and have the chance of getting a fix (that includes the chance that somebody will be willing to try and find and fix the problem if it still exists) than not upgrade and continue to put up with the problem. Of course the choice is yours.

Warm regards,
mm

 

[Owlsroost]

I agree with mm1352000 that you should try LAV codecs/upgrade to 1.2.3, but if you want to experiment with a more modern TsReader.ax try 'noStopMod59c.zip' from https://forum.team-mediaportal.com/threads/experimental-tsreader-development.102693/#post-811296 - I think this will work in MP 1.1.x but I've never tried it....

From the working/non-working TsReader log fragments I suspect this is more of an audio decoder problem than a TsReader problem (the decoder is apparently connected, but the DirectShow filter graph manager isn't starting the loop that transfers data from TsReader output to decoder input), but it's hard to know for sure.

Tony

 

[cewillis]

mm and Tony,

First, I am working on upgrading to 1.2.3 (carefully so as not to lose existing functionality, and slowly with several other things going on), but I will definitely try the LAV codecs/filters first.


mm,

"I can't guarantee anything (about 1.2.3), and probably nobody else can either." I take your points about this and about upgrading -- people in the original thread had pretty much convinced me, but I am MUCH happier knowing that there IS a real problem even if not completely understood.

I see the differences you point out. Thank you. But some questions ---
1) Do the problems you found explain the behavior; ie, if 'connecting audio' fails, and 'aud:OnThreadStartPlay...' doesn't happen, does that mean that MP would appear to hang up, and be unresponsive to any input except 'Stop'. (which is what I actually see). To an amateur, it might seem instead that the video would play, but with no sound.

2) Could these problems be related to any hardware drivers?

3) 'codec may not be able to handle the encoding format and options that your provider uses perfectly' This would seem to imply that a specific problem recording would always fail -- but that's not the case. There is no rhyme or reason about what recording will fail, and when a failure occurs, a reboot 'always' fixes it. (at least every time so far)

4) Why does a reboot fix the problem? Doesn't that imply that 'something' got into a 'messed up' state? (to use a technical term).

I do NOT ask or want you to spend any more time trying to definitively pin this down. If you have a quick thought about the questions, that would be great, but otherwise many, many thanks -- and I'll post here what happens with the LAV filters. (of course, all I'll know is that the problem hasn't recurred - yet)

Best,
Cal

 

[cewillis]

LAV filters installed and MP configured to use them without incident at 8:30 am, Arizona time on July 26, 2012.
All working.
Waiting ---

Edit: Tried 8 - 10 manual resume and start playback today so far. All worked fine.
I notice 1 obvious change: prior to LAV filters, there would usually be a delay of 1,2 - 5 seconds between initiating playback and playback actually starting (if there was no 'hangup'). Now, playback starts essentially instantly - < 1 second.
Too soon to tell if there is an improvement in video quality. Should there be?

 

[mm1352000]

Hello again Cal

1) Do the problems you found explain the behavior; ie, if 'connecting audio' fails, and 'aud:OnThreadStartPlay...' doesn't happen, does that mean that MP would appear to hang up, and be unresponsive to any input except 'Stop'. (which is what I actually see). To an amateur, it might seem instead that the video would play, but with no sound.

I think Tony would be able to give a better answer than me, but my understanding is that TsReader doesn't support video without audio. Don't quote me on that though (and Tony please do correct me if I am wrong! ).

2) Could these problems be related to any hardware drivers?

If it is a TsReader problem then I think it is highly unlikely. For a codec problem I guess it is possible in general (for example if the issue were DXVA related or something) but in this case I doubt it. Again, Tony please don't hesitate to correct me.

3) 'codec may not be able to handle the encoding format and options that your provider uses perfectly' This would seem to imply that a specific problem recording would always fail -- but that's not the case. There is no rhyme or reason about what recording will fail, and when a failure occurs, a reboot 'always' fixes it. (at least every time so far)

My understanding is/was that playing a recording is a deterministic, mechanical process for TsReader and for codecs. In other words, all things being equal the video should either play 100% of the time or not play 100% of the time. Any variation from that would suggest that other influences may be involved. In this particular case there appears to be inconsistency, but I just can't think of any outside influence that would cause the TsReader not to be able to connect to the codec. In that respect the issue doesn't make logical sense. In the absence of a better understanding or explanation I have suggested actions that should help to clarify the problem if they don't resolve it.

4) Why does a reboot fix the problem? Doesn't that imply that 'something' got into a 'messed up' state? (to use a technical term).

I honestly don't know. I can only rehash my answer to Q3: it does seem to imply that something got messed up, but I can't explain how or why either TsReader or codecs would behave this way.

Edit: Tried 8 - 10 manual resume and start playback today so far. All worked fine.

Well that is a good start.

I notice 1 obvious change: prior to LAV filters, there would usually be a delay of 1,2 - 5 seconds between initiating playback and playback actually starting (if there was no 'hangup'). Now, playback starts essentially instantly - < 1 second.
Too soon to tell if there is an improvement in video quality. Should there be?

In video quality? LAV does have a bunch of settings for things like RGB range conversion, dithering and deinterlacing. You may notice video quality changes if you dive in and start tweaking things. For the "casual user" it is usually "much of a muchness".

mm

 

[cewillis]

Sorry to say the problem occurred again last evening. Same symptoms as before: selecting a recording for playback leaves MP apparently dead, time stops incrementing and no remote input works, except stop. Then MP is back to normal, except trying to play repeats the cycle.
The next time this happens, would it be useful to look at Task Manager -> Processes to see if anything is using up CPU time?
I'll also try different audio renderers, and maybe update some motherboard drivers.

Oh well, LAV filters are definitely an improvement. I keep heading toward 1.2.3 and hope the problem is not there too.

Many thanks, mm, and Tony too.
Cal