Skip / fast forward not working - random intervals and direction

[OTAjunkie]

I'm notoriuos for corupting my registry but quite comfortable with merging *.reg

Could the final fix key info be posted and I'll make the file? x86 in my case

[sub]

I'm notoriuos for corupting my registry but quite comfortable with merging *.reg

Could the final fix key info be posted and I'll make the file? x86 in my case

Just to be clear, that BlockEncrypted registry stuff I discussed on the last page was only really aimed at WKleeven, and was specifically related to some garbage he was getting at the begining of recordings when decrypting DVB pay television signals - it wasnt about some generic skipping issue, and wont make any difference in your part of the world.

[WKleeven]

In post #157, date 10-oct-2011 everything worked normal. And I had the registry setting set to 1. Which doesn't matter, cause NPVR doesn't read.
Then I put back an image dating 05-oct-2011 put the registry in and to 1, installed R2P and got the timeline issues.

It looks like you forgot to add the registry setting to not write encrypted data. The first 15k blocks of the B&B file are invalid casing NPVR to think you are 5772 seconds into a 346 second file.

Martin

Martin thinks not setting the registry setting makes NPVR not ignore encrypted data.

Your patch makes NPVR see the registry setting (1) correct. This causes the timeline problem??
But why then did I have those timeline problems before 10-oct-2011?


Tonight I got 3 correct recordings and 1 odd one. I will do some more testing in the morning.

Wim

[sub]

As Martin pointed out, your playback problem with some recordings related to encrypted packets at the beginning of the recording. You've never been able filter out encrypted data, due to a spelling mistake on the setting name. I supplied a patch which corrected the spelling, allowing you to try this BlockEncrypted logic for the first time, but you found it wasnt working and caused problems, so you've had to disable it to get back to how you were originally. ie, you'll probably have some encrypted data at the start of recordings.

Having some encrypted data at beginning of recordings isnt always going to cause a problems. It probably depends how much encrypted data there was (ie, how quickly it got the keys), and whether any of that data included PCR clock values. When you start playback on an MVP, it'll monitor a chunk of data at the start of the file looking at clocks etc, and your problem most likely happens that beginning chunk of data is all encrypted, or contains bogus clock values.

Just to be clear, the BlockEncrypted logic hasnt changed in about a year or so, which was when I first attempted to add it, so it wasnt working for you a few weeks ago. This logic was originally written for hardware CI devices, and doesnt like the way ffdecsa delivers decrypted chunks of data when attempting to use it with multidec plugins.

[OTAjunkie]

Thanks Sub,

My issue is during live TV. My "Skip Back 30s/ Skip Forward 60s" don't work on the Win7 as described.
Any thoughts?

[sub]

My issue is during live TV. My "Skip Back 30s/ Skip Forward 60s" don't work on the Win7 as described.
Any thoughts?

What exactly happens?

I'll probably need to get you to reproduce it in a recording, so we can get a nice repeatable test, so we can incrementally try changes, add more logging, repeat etc.

[OTAjunkie]

I just got in and tried it after a 15 min run of live tv, uh, it seems to be working now. Which is great but I'm scratching my head. Yesterday I rolled back to R1 patches and rebooted and it didn't work. The "tape" would go back to where the channel started and play, and no other command would have any effect other than "Esc" back to guide.
So it appears I'm good.
Thanks all the same.

[WKleeven]

Sub,

Did some more testing. After a reboot this morning, today NO recording has a normal timeline on the MVP (registry setting=0; dongle 09-10-2011 12:32:06, restart recording service). I noticed that the timeline on the PC is normal (that is, when the video starts after a few seconds black screen, the time is already 00:00:05 or something, but I thinks that's normal).

With the registry setting to 1, I get recordings of 00:00:00 seconds and for example 5.077 kB when I recorded say 30 seconds. So I think there must be encrypted packets not only at the beginning of the recording, but during the whole recording? (or 15.231 kB, 00:00:00 seconds with a few minute recording). I can understand NPVR can't play that back, nor can windows mediaplayer and it crashes the MVP.


What I don't understand is that yesterday evening, 3 out of 4 went normal. Today 6 out of 6 went wrong. I even started newcs.exe instead of newcsgui.exe just to be sure that's not causing a problem.
And what I don't understand is that after Martin fixed the dongle everything was working normal on 10-10-2011.
In post 158, I also wrote that I got 1 recording normal and after that only wrong timelines on new recordings that day.
The problem is very inconsistent.

I also tried another ffdecsa, but no luck either.

Any ideas? Maybe with the registry setting to 1 and the 0 seconds recording?

Wim

[sub]

Any ideas? Maybe with the registry setting to 1 and the 0 seconds recording?

To get rid of these encrypted packets you're pretty much going to need me to fix that BlockEncrypted so that it also works for multidec decrypted channel. Unfortunately I haven't got any time available right now to do that.

[WKleeven]

Okay, the good news is that can fix this, the bad news is that it won't be fixed soon.

When do you think you will have time for it? Perhaps it's best to disable the digital card for now, to prevent WAF problems regarding skipping.
If you need my help (testing or otherwise), let me know.

Wim

p.s. I also got some other issue, I will post about it in another thread.