ts-mux multi-record conflict

[spicy]

This question is for the QAM side of recordings with an HVR1600.

I've been working on this issue of the posts for about two weeks and I can't solve it. I am hoping that someone can shed some light on this and I preemptively apologize if it turns out to be something that I clumsily overlooked.

On previous release I was able to record about 6 QAM channels at one time; life was sweet. But I upgraded to 1.3.11.... I encountered "channel conflict" when trying to record a second channel of the QAM with same frequencies (ie T:595250,0,0~P:2~V:89~A:91/T:595250,0,0~P:6~V:68~A:72).

After reading the posts and seeing that this problem was unique to me I decided to roll back to the previous working version. Lo and behold no more QAM conflicts... but ... recordings kept crashing and hanging. Reading more posts and applying some fixes recordings kept crashing. So this A.M. I decided to go forward and again installed the current version. I applied one posted fix which seemed like it was applicable to my situation - ref-patch - but its magic was not be with me.

I am again encountering "channel conflict" when trying to record a second channel of the QAM with same frequencies. Has anyone encountered this situation and if so can some light be shed on this? Thank you for your help.

[sub]

Try scheduling multiple recordings at the same time from the TV Guide, then zip and attach the pvrx2.exe.log and I'll take a look for you.

[spicy]

I'm attaching my Logs directory in RAR format since the requested file is there. I've also placed in that directory a jpeg with screen captures of my problem. As a test, from the TVGuide, I recorded 3 analog, 1 QAM, and the screen is the error I get from trying to record the 2nd QAM. Included in the jpeg is a screen of my mappings from querying the db3 file. I hope I did not just inundate you with too information!

I thank you in advance.

[sub]

This is what I get in the logs:

2009-02-05 11:13:15.593 VERBOSE [1] Checking if multi-record possible on capture source...
2009-02-05 11:13:15.609 VERBOSE [1] New recording is encrypted, so isnt compatible with 'multi-record'

[spicy]

Whoa! Very interesting. Perhaps that is why I was crashing in the previous version?; although I was getting recordings right up to this monday (2/2). Sporadic, but still recording simultaneously (QAM). It would record on the first recording of the day (two simultaneous) then hang for the rest. I would reboot and begin anew.

Thank you so very much for steering me in this direction. I must digest this for a couple of days and test out some new theories based on your most helpful information. I will share my findings once obtained.

[spicy]

After scanning/testing frequencies I've come up with these inconsistencies:

1. My HDTV capable TV picks up HD (unencrypted) straight from the cable (no box)
2. WinTV6 has no problem picking up all available HD frequencies (unencrypted)(no box)
3. Using 1.3.7 I can pick up HD frequencies (unencrypted) but crashes. (recordings hang)
4. All HD frequencies on GBPVR come up as encrypted (1.3.11) . (the same frequencies that WinTV can pick up and the same frequencies used in 1.3.7).

My question is....why?
Has something changed in the tunning process between versions? I saved the frequencies (cache file) that was working on 1.3.7 and cut and pasted them on 1.3.11. I also copied the working frequencies used by WinTV and tested them as well.
...or might WinTV be using a different driver for tuning?

Again this is not a pressing issue, but if you have time can you share your thoughts?

[sub]

Is it just a matter of 1.3.11 incorrectly identifying the channels as encrypted during the scan, but finds all the channels, and can watch all the channels that are really unencrypted? The only place the encrypted flag is used is when scheduling a multi-recording. Its ignored the rest of the time (live tv etc).

[spicy]

I'm sorry but I don't think I quite understand your question but ....

1. 1.3.11 scans channels and provides frequencies - those not encrypted (forced by me) cannot be viewed (crashes after 15 seconds and tells me its encrypted) or tells me that it's encrypted (no view) ... but I can record (one at a time).
2. Not 'all' available channels are provided during scan... even those whose frequencies I derived from WinTV. (by providing them in the qam.ini file)
3. 1.3.7 scanned and provided those frequencies in par with WinTV. But hung on recordings.

Can I 'unflag' them in the database after scanning and/or after providing my own known working frequencies (copy paste) to see if it works? If so where/which table, is it in?

Thank you.

[sub]

1. 1.3.11 scans channels and provides frequencies - those not encrypted (forced by me) cannot be viewed (crashes after 15 seconds and tells me its encrypted) or tells me that it's encrypted (no view) ... but I can record (one at a time).

Reproduce this, then zip and attach the logs and I'll take a look.

2. Not 'all' available channels are provided during scan... even those whose frequencies I derived from WinTV. (by providing them in the qam.ini file)
3. 1.3.7 scanned and provided those frequencies in par with WinTV. But hung on recordings.

Do you have this patch from the survival guide installed: http://forums.gbpvr.com/showpost.php?p=3...ostcount=7

Can I 'unflag' them in the database after scanning and/or after providing my own known working frequencies (copy paste) to see if it works? If so where/which table, is it in?

The SOURCE_CHANNEL_MAPPING table, tuning_request' column contains the tuning information. Removing the "~E:T", will remove the flag that makes the app think its encrypted.

I'm surprised all your channels are showing up as encrypted on 1.3.11. I had several people test this prior to 1.3.11 being released. Or was this on an existing capture source (which might have incorrectly marked them as encrypted in an earlier scan)? 1.2.x was marking all channels as encrypted.

[dennit]

The SOURCE_CHANNEL_MAPPING table, tuning_request' column contains the tuning information. Removing the "~E:T", will remove the flag that makes the app think its encrypted.

Thanks for this info - I was wondering what made the app think a channel was encrypted.

I'm surprised all your channels are showing up as encrypted on 1.3.11. I had several people test this prior to 1.3.11 being released. Or was this on an existing capture source (which might have incorrectly marked them as encrypted in an earlier scan)? 1.2.x was marking all channels as encrypted.

I had a channel under 1.2.13 that always popped up a box about 15 seconds after starting to watch it live. The warning box claimed it was encrypted, even though the channel played fine behind the box. I haven't looked at this channel since I upgraded from 1.2.13 to 1.3.11, and I never recorded it, but perhaps removing the "~E:T" will fix it.