Recording service crashes

[Bobins]

Sub,

This afternoon I've scheduled 20 recordings overlapping accross the two tuners and the recording service hasn't crashed. The only thing that's different between this and the crash scenario is that there's always a reoccurring recording running when the crash happens.

Also noticed that if I do an update to an existing recording and change the channel, the Name Prefix which always identifies the channel doesnt change. (e.g. Name Prefix says BBC1 but the channel is ITV1). Is that by design?

[pauld]

Hi Sub,
Hope this is the right place to post this – please correct me if I am wrong as this is my first post ever, on any forum!
Anyway, here goes – I have been using GBPVR since last November and lurking in the forum soaking up all the great advice from the experts, but I still have what I think is a fundamental problem in that the GBPVRRecordingService often consumes 99+ % cpu after it has started a recording. I am not sure if this is to do with the Service not starting after a reboot (have included error information from Event Viewer Application Log entry in the zip with the GBPVR logs). The result is a 0kb mpg file and I can only reduce cpu load by manually ending the GBPVRRecordingService process in Task Manager, then Slimm restarts it. This doesn’t happen for every recording, but I can’t see a pattern.
During other recordings the cpu load is around 3-4% so I don’t think it’s a processor issue and although we are on the edge of a digital area, the signal isn’t bad – I first thought it was a signal issue, but after todays problem Live TV was fine on the same channel and the STB upstream of the tuner was fine for the whole show.
(I have tried re-registering the filters, but get a whole mass of cpu activity and multiple instances of regsvr32 in Task Manager that don’t want to stop even after a couple of hours!!)
It really looks like the mpg is not growing in size, so I tried using the PowerControl utility a couple of weeks ago, but keep getting a “Runtime error ‘9’ – script out of range” when I run “Timer”, but as the guy who developed it rightly said it would be best to fix the underlying problem, so here I am!
Hope you can help as I am beginning to tear out what little hair I have left!!
If you need more info than is in my signature or need to point me at another thread please let me know.
Many thanks

[sub]

Hi Sub,
Hope this is the right place to post this – please correct me if I am wrong as this is my first post ever, on any forum!
Anyway, here goes – I have been using GBPVR since last November and lurking in the forum soaking up all the great advice from the experts, but I still have what I think is a fundamental problem in that the GBPVRRecordingService often consumes 99+ % cpu after it has started a recording. I am not sure if this is to do with the Service not starting after a reboot (have included error information from Event Viewer Application Log entry in the zip with the GBPVR logs). The result is a 0kb mpg file and I can only reduce cpu load by manually ending the GBPVRRecordingService process in Task Manager, then Slimm restarts it. This doesn’t happen for every recording, but I can’t see a pattern.

Whats the output of MuxChecker on your machine? Some versions of the Cyberlink mux cause problems like this (for example v5.0.0813).

[pauld]

Hi Sub, thankyou for such a quick reply.
MuxChecker output is:
"GB-PVR has detected the following multiplex filters on your machine:

Found: CyberLink MPEG Muxer
FILE: C:\Program Files\KWorld Multimedia\DVB-T PLUS\DTVR\MpgMux.ax
VERSION: 5.0.0813

If you're running WinXP SP1 or higher, you will also be able to use the built-in DVR-MS mux filter"

Although i had the ATI Mux registered I read in one of the forums that the Cyberlink Mux was a good one and it loaded with the K-world USB I bought befor reading the forum!
Hope this is what you are looking for.
Paul

[sub]

As I said above, 5.0.0.813 is known to cause the occasional zero byte or partial recording, and sometimes use 100% of the CPU. The fix is to upgrade to a later version of the Cyberlink mux (5.0.0.1307 is a good one), or switch to the ATI mux.

[pauld]

Thanks Sub, I'll get right on it. Any tips on where to get hold of the 1307 version or shouldn't I ask?
Paul

[sub]

Any tips on where to get hold of the 1307 version or shouldn't I ask?

I dont have any download link for you, but it has been mentioned in threads in the past.

[pauld]

Hi Sub,
I remember reading about this some time ago now, I went to the Twinhan site recommended by Dave47 but couldn't find the .ax file he was talking about (http://www.twinhan.com/download_driver&software.asp) but I've had a closer look and found in the software section, "TwinhanDTV 2.65", clicked the download button to get "TwinhanDTV 2.65 Build 01-02.zip" (it's about 22.5Mb, but the Mux is labelled "THMpgMux.ax" dated 30/8/2005 16:31 and extracts to a folder called "3rdPartyApp").
Will go and register this on our media PC tomorrow - I need some sleep now as it's nearly 2.15 am!!
Many, many thanks for your help - hope the above helps others too.
Regards
Paul

[pauld]

Hi Sub,
Have registered the newer Cyberlink Mux (to correct my previous post the version is 5.0.0.2022 from that source - now shows in MuxChecker) and unregistered the older one.

Can I assume this version is a good one or should I continue to look for 1307?

Anyway, fingers crossed (although all of todays recordings were OK with the older Mux).
Many thanks for your help.
Paul

[sub]

I havent used that specific version myself, but I'm guessing its better than 5.0.0.813.