ts-mux multi-record conflict

[sub]

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.

Sorry, but that wont make any difference. The '~E:T' indicator isnt really used for anything other than some of the decisions around multi-record.

The box popping up to say it was encrypted was happening because data wasnt flowing to the video decoder (either because it was encrypted, or there was no signal, or PIDs changed since the channel was originally scanned).

[dennit]

Sorry, but that wont make any difference. The '~E:T' indicator isnt really used for anything other than some of the decisions around multi-record.

The box popping up to say it was encrypted was happening because data wasnt flowing to the video decoder (either because it was encrypted, or there was no signal, or PIDs changed since the channel was originally scanned).

OK, but with that explanation I'm confused as to why the channel continued to play so well behind the box. If the PID changed since scanning, would it tune at all? I watched the channel for 5 minutes after the box popped up and it seemed to play just fine around the edges of the box. Would this be a sign of a poor signal or possibly some interactive data service on one of the streams, or should I scan again?

It's not really important, since I don't watch that channel, but I was curious.

[sub]

OK, but with that explanation I'm confused as to why the channel continued to play so well behind the box. If the PID changed since scanning, would it tune at all? I watched the channel for 5 minutes after the box popped up and it seemed to play just fine around the edges of the box. Would this be a sign of a poor signal or possibly some interactive data service on one of the streams, or should I scan again?

It was probably caused by multidec or tuning taking too long to start delivering data, and the app had already decided to show the box prior to the real data starting to flow. It probably stayed there because the app wasnt correctly detecting that the data was now flowing and the box should have been removed.

There is a setting in the config.xml which could be used to increase the timeout, but the name escapes me at the moment.

[spicy]

I'm sorry for taking so long to reply.

After applying the patch suggested and wrestling with the frequency conflicts and constant crashes I did what any respectable XP user would do...... I reinstalled windows for the nth time. Miraculous enough, my frequency conflict problems went away. I'm thinking a corrupted file somewhere. With this new build I also placed an amplifier on the cable which boosted my scanning and also (I think) solved the "encrypted" of non-encrypted channels. I'm happy to report that for the past few days your program has worked effortlessly.

Kudos for all your work and as always you are on the mark! I thank you so very, very, very much for your help.