Barleyman Posted February 16, 2010 Share Posted February 16, 2010 (edited) It looks like recording service has a problem with recordings over 64GB, at least with 32bit W7. Before you ask, overnight olympics programme, HD. Whole night of olympics takes about 90GB, give or take. 1st night I let it all go to one big file, worked fine until the 64GB mark, after that blank. 2nd night I tried to be clever and told recording service to split files at 32GB. Result: two files ok, 1 file garbage. I suppose telling recording service to stop and start the recording in the middle would help, but.. I added a 100k chunk of the 3rd file. According to mpegfix, "Error: TS Packet has payload_unit_start_indicator but no PES header" Edited February 16, 2010 by Barleyman Link to comment
Griga Posted February 16, 2010 Share Posted February 16, 2010 TS Packet has payload_unit_start_indicator but no PES header That's true. Looks like video/audio including the PES headers weren't decrypted, though the scrambling flag in the TS headers is set to 0 (otherwise the RS would discard the packets, as far as I know). CI/CAM problem? Link to comment
Barleyman Posted February 16, 2010 Author Share Posted February 16, 2010 That's true. Looks like video/audio including the PES headers weren't decrypted, though the scrambling flag in the TS headers is set to 0 (otherwise the RS would discard the packets, as far as I know). CI/CAM problem? If that's so, it's very specific one. Here's a chunk from the end of the previous file (of 32768MB), cut at the end of the file. (well, skip 100k times 310k) Link to comment
Barleyman Posted February 17, 2010 Author Share Posted February 17, 2010 As I suspected, splitting the 11 hour recording to 2 separate sessions fixed the problem by avoiding >64GB recording session. As you could see from the 2nd file chunk, <64GB everything is fine, >64GB it's not. How is the cable card connected to this problem? Maybe rec service CI interface dies at that point? Link to comment
Barleyman Posted February 18, 2010 Author Share Posted February 18, 2010 If I can demonstrate the problem on Iphone, will it get addressed? Link to comment
Griga Posted February 18, 2010 Share Posted February 18, 2010 How is the cable card connected to this problem? Who knows... it's quite unlikely that this problem can be solved in the RS. It records what it receives, and it's very clear that decryption stops for some reason. The packet structure is ok, the packet headers are ok, PAT, PMT, everything that is not supposed to be encrypted is ok in the file. But the scrambled flag is not set in the TS headers, and that's not ok, because obviously the content is scrambled. That means, something has changed the original flag (most likely something deep down on the driver/hardware level), assuming that decryption is still going on, but actually it isn't. If the RS would have stopped decryption in some way, the scrambling flag would be set (AFAIK the RS doesn't change it), and the RS would discard the data, which means, nothing would have been recorded anymore. Maybe rec service CI interface dies at that point? The RS has no CI interface, it uses a CI interface provided by the driver. Link to comment
Barleyman Posted February 19, 2010 Author Share Posted February 19, 2010 Hmm. You still haven't opened the "good" file chunk, is there something fundamentally different between the two samples in terms of being flagged? Splitting the overnight recording into two separate sessions corrects the problem, so obviously RS activity does interact with the problem at some level. I thought the programs are decrypted when watched but saved as-is. Link to comment
Recommended Posts