soccerdad Wrote:I applied the patch and it looks like it is working great with multirecord on. I get recordings very quickly and so far no zero bytes even switching sats. I also do not get the zero byte then recording like I got without multi record on.
I will keep testing but it looks like it has solved the problem.
Thanks.
Thats great.
I'm not sure why it would have been any different for any other mux though. In 1.3.11 I removed the logic behind <BDASubmitTuningRequestTwiceOnRecord> hoping it was no longer needed. Your device seems to still need it, so was still tuned to the old channel. Unless of course your non-zero recordings for the other muxes didnt actually contain the correct channel (since they only record a specific audio/video pid, wheras TS Mux requires a correct 'program number' which was not present in the previously tuned frequency).
My results are variable. I'm still getting mostly 0 byte files. When trying multirecord, the first file recorded is 0 byte. I'm not seeing the second 0 byte file being created. The settings are multidec and multirec on.
If I try to multirecord a second file while the first remains at 0 bytes, the second (which should be still encrypted) records, although I haven't yet succeeded in offline decrypt.
I don't know if it helps, but here are sets of logs and .txt files for first a single record from DVB-S (created a 0-byte) and then a new attempt at recording with a first file (should have been handled by multidec) and a second (should have been recorded encrypted). The first stayed at 0, the second was created.
It helped me. I'm early in my testing, but it's worked twice. I haven't yet tried turning off <BDASubmitTuningRequestTwiceOnRecord>.
Will keep you advised as testing proceeds. Again - you are amazing - thanks!
dennit Wrote:It helped me. I'm early in my testing, but it's worked twice. I haven't yet tried turning off <BDASubmitTuningRequestTwiceOnRecord>.
Will keep you advised as testing proceeds. Again - you are amazing - thanks!
It's worked 5 times straight. Last 2 times it worked with:
<BDASubmitTuningRequestTwiceOnRecord>false</BDASubmitTuningRequestTwiceOnRecord>
and a multirec second recording started correctly in both cases.