Invalid MAK error

[jagedge11]

I am using cTiVo 3.5.2 and using a TiVo Roamio OTA, but this has been happening on older versions of ctivo as well. Occasionally I get DL Stage Failed on a show (a couple dozen in the last few years). Happens rarely, but I decided to look into it this weekend. I looked in the logs and I see:

2022-07-02 13:20:39:563 -[MTTask failedTaskCompletion]@246>Task decrypt failed
2022-07-02 13:20:39:563 -[MTTask saveLogFileType:fromPath:]@208>errFile for task decrypt: Encryption by QUALCOMM ;)

TiVo Header : 
 flags : 13
     origin : US
     format : Program Stream
     source : SDTV
  TiVo unit : Series3
mpeg_offset : 20480
chunks      : 3

Invalid MAK -- aborting
processing frame: Undefined error: 0
Failed to process file: Undefined error: 0

I then manually downloaded the file using curl. I then tried to decode the file using tivodecode and it failed.

Encryption by QUALCOMM ;)

TiVo Header : 
 flags : 13
     origin : US
     format : Program Stream
     source : SDTV
  TiVo unit : Series3
mpeg_offset : 16384
chunks      : 3

Invalid MAK -- aborting
processing frame: Undefined error: 0
Failed to process file: Undefined error: 0

So I added the -n option to tivodecode and it worked.

I'm thinking maybe you could add this option as a fall back in cTiVo if this problem occurs until tivodecode gets fixed. This worked with all the files I had trouble with that were still on the TiVo.

[mackworth]

I'm not surprised that it occasionally fails; we're generally seeing increasing corruption on the files being downloaded. (Which cable provider BTW?) Although usually it's during the encoding process.

While disabling error checking will obviously let tivodecode complete, but the question is whether the resulting file is useful. When you use -n, is the resulting file actually viewable, or is it just trash? You may need VLC to view it.

Have you tried TiVoLibre on the same files? (You'll need the Java runtime to try it).

[jagedge11]

I am using OTA so no cable provider, but a variety of channels these files came from NBC, Comet, The CW, PBS, ABC and CBS. I don't see any pattern to the channels. It rarely happens, but I was running low on space so I wanted to delete these that I had kicking around.

I used VLC to view the files and I didn't see any issues with the files. The files actually look better than normal since no additional compression is happening. I jumped thru about a dozen of them every 10 minutes and they looked and sounded great. None of the files have subtitles, since I didn't try and figure out how you were doing that, maybe later I'll put all this together in some kind of Automator service if I can figure out the subtitles. I am an old embedded software engineer so not much experience in GUIs.

If you don't think a fallback would be appropriate maybe an advanced option checkmark that could be used on any files that fail or an option to try one more time with -n.

I don't think it's a download from the TiVo issue since I'm hardwired and this only happens rarely, but repeatedly on the same program even after restarting everything.

Maybe an issue during the channels original encoding of the program, but it would surprise me if they weren't encoding the files more than once and doing a verify and it's happening on the major networks CBS, NBC and ABC.

I'll take a look at TivoLibre, but I have been very happy with cTiVo other than these rare problem programs.

[mackworth]

That's fascinating. (aka "shut my mouth" about "useless files").

I'd be good with adding a option for that, but first I'd like to see if I can understand what's happening.

Can you post one or more of the undecoded files somewhere, then email the links and MAK to me at mackworth at aol dot com? I'm not a tivodecode expert, but I'd love to walk through the validation section w/ the debugger. I have a theory on what might be happening.

Subtitles use ccextractor, available in the cTiVo bundle, callable from command line. You'd then need ffmpeg or subler to add the caption track to your mpeg. Call to ccextractor looks something like: ccextractor -utf8 -s <INPUTPATH>> -o <<OUTPUTPATH>>

(BTW, TiVoLibre is a alternative implementation of tivodecode; it's included with cTiVo. If the Java run time is installed, you can just select it in the Adv Preferences to see if it gets through these files ok.)

[mackworth]

So I did get a file from someone with this exact same symptom, and found that it's due to MAK validation in tivodecode failing if the first video slice in a PS transfer happens to be too short. Turns out this validation actually isn't necessary, as we can't download the file in the first place w/o the correct Validation. So, I can just turn off the validation, and everything works great. The upcoming version 3.6 will have this fixed.

[jagedge11]

Thanks, looking forward to it…John

On Mar 9, 2023, at 3:07 PM, Hugh Mackworth @.***> wrote:

So I did get a file from someone with this exact same symptom, and found that it's due to MAK validation in tivodecode failing if the first video slice in a PS transfer happens to be too short. Turns out this validation actually isn't necessary, as we can't download the file in the first place w/o the correct Validation. So, I can just turn off the validation, and everything works great. The upcoming version 3.6 will have this fixed.

— Reply to this email directly, view it on GitHub https://github.com/mackworth/cTiVo/issues/494#issuecomment-1462948905, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZ4TFFX7YMR4PYH5TUK3PYLW3JPEJANCNFSM52QHYOCA. You are receiving this because you authored the thread.

[mackworth]

Actually 3.6 beta is available here