1.5.28 beta available (7th Aug)

[mvallevand]

Here's my setup and I get fantastic a/v performance with NPVR using an old G945 IGP even running much hated Vista.

Martin

[sub]

Yes, this will work for *.MPG files with MPEG-2 inside, but *.MPG with MPEG-1 will fail to play, "MPEG-I Stream Splitter" needs to be used. So i think forcing one filter is not good idea.

MPEG-1 .MPG files wouldnt have been recorded by GBPVR. I'm happy to add playback support for MPEG-1 files if you provide a sample though.

BTW, can i ask why MPG needs to have special handling and they are not played like other media like AVI/MKV,etc...? Is there any particular reason? Why it just dont ask DirectShow to play it?

The first release of NPVR did exactly what you suggest, but I quicly realised this was not going to be adequate. Alot of people here have .MPG files, and leaving it up to Directshow was resulting a large percentage of users not being able to play .MPG files. Users were getting black screens, or hung video, or bad choices of decoders, no hardware acceleration etc. To fix, I added the special logic to ensure a working graph was built, using the decoders the user had selected in the settings screen. Very few people use MPEG-1 files, so your particular issue hasnt come up before.

[hoborg]

sub, i doesnot like this, but understand it. It is too bad, becouse thanks to this i cannot play MPG files by using my SAF any longer.
Maybe you can add option how MPG graph build should be handled.

And you can get some MPEG-1 samples here.

[sub]

sub, i doesnot like this, but understand it. It is too bad, becouse thanks to this i cannot play MPG files by using my SAF any longer.
Maybe you can add option how MPG graph build should be handled.

In the next release you can set <ForceMpgGraph>false</ForceMpgGraph> in config.xml to allow directshow to give a default graph for .mpg files.

It'll default to 'true' for the reasons I mentioned above though.

[hoborg]

Great, thanks.

[mvallevand]

Great, thanks.

If you rename your mpeg-1 files to .mpeg you might be able to play them today since NPVR keys on .mpg

Code:

2010-08-16 19:33:53.816    [DEBUG][1]    Adding EVR renderer
2010-08-16 19:33:54.264    [DEBUG][1]    Graph filter list:
2010-08-16 19:33:54.265    [DEBUG][1]     - EVR Renderer
2010-08-16 19:33:54.265    [DEBUG][1]     - MPEG Video Decoder
2010-08-16 19:33:54.265    [DEBUG][1]     - MPEG-I Stream Splitter
2010-08-16 19:33:54.265    [DEBUG][1]     - C:\movies\tomb.raider.sample.mpeg

Martin

[sub]

If you rename your mpeg-1 files to .mpeg you might be able to play them today since NPVR keys on .mpg

Good point. Yes, that'd work.

[hoborg]

If you rename your mpeg-1 files to .mpeg you might be able to play them today since NPVR keys on .mpg
Martin

Renaming files is not solution. How you will rename them if they are burned on DVD?

BTW:
New LAVFSplitter is slowly coming out - one splitter to rule nerly all local formats.

[kendrak24]

It looks like the 'Recording service not running at recording time' issue is solved (at least for me, I only had it with recurring recordings where I kept only 1 episode).

I still have the issue. Approx. once every week / two weeks it happens (no pattern) and once it started all subsequent recordings will "fail"
with the "Recording service not running at recording time" message.
However, the actual recording is done so the .ts files can be viewed externally (or through Videos).
Also when this happens, the recording service cannot be restarted, I need to kill the nrecord process.

[johnsonx42]

That's a different issue Kendrak. The original issue related to a problem with the EPG reload - part of the recording service would have an updated recording schedule with new recording ID's, while the back-end part actually making the recordings would still have be using the old schedule with old recording ID's. So the two halves were never on the same page; the back-end would keep making recordings, but with different recording ID's than the database engine was expecting, so the database would keep thinking all the scheduled recordings were still pending and would eventually "fail" them when the recording schedule finally did get reloaded. That issue has absolutely been fixed.

Your issue is more along the lines of a recording service crash. You should start a thread in the support forum and post logs.