MacOS Sonoma Issues

[ghost]

There are some changes coming soon. Here is a log file from crippling errors from the fall changes.

I fixed the Failure to initialise thread 'VideoToolbox encoder (Apple) error, I think, by giving the handbrake rights to run and giving ctivo the rights to process information using other apps but still if fails.

libdvdread: Encrypted DVD support unavailable. libdvdread: Can't open file VIDEO_TS.IFO.

com.cTiVo.cTiVo 2023-07-16--10-01-17-331.log

[ghost]

OK, so I got it to work by simply asking for a decrypted file. So, it seems the connection between cTivo and handbrake is broken. No more automated pass over to process mpg's behind the scenes.

[ghost]

This is what I get when I try to open cTivo settings

[mackworth]

So I assume this is Sonoma's public beta? Sigh. Haven't loaded it yet.

Apple's now preventing access to Sandboxed data. I've got some old code in cTiVo when I was expecting to support Sandboxing, allowing one to go back and forth. Apple said "TiVo has to approve" to get in App Store, so I canceled that project. Did you get the "would like to access" message" on first startup? If so, that's the cause, and I can easily remove that code to avoid that message. If you get it when opening Settings (first time on every launch?), then that's just weird.

Did you get an error/access message on Handbrake when first starting? Did you try saving to Apple TV app?

The Video_ts.ifo message is normal; that's from Handbrake's history of working with DVDs.

Yes, decryption avoids Handbrake, but Handbrake is clearly starting properly, but it's then failing on the "Magic Cookie" error. I'm not seeing that error fixed in the log you sent. Every run fails with that error. That's specific to VideoToolbox encoding in HB, so try running with the software encoder and see if that works. Also, does VT work if you run Handbrake from the UI?

Reading their code from that, I don't know what the cookie is for, but I see that they have to compress a frame to get that cookie. The compression goes fine, they get a format, and then extensions, and then magic cookie access fails. So that's odd that that is OS-dependent. No permissions problem there.

[ghost]

Handbrake in and of itself runs fine, no errors or permission prompts. I put a file in it and the file encodes using the same profile (VT) I have reference in cTivo. I believe it is a cross app permission issue. Every time I use file > settings that permission prompt comes up. Just for testing purposes I gave cTivo permission for full disk access, still no good.

[mackworth]

Okay, and does the non-VT ones fail (eg HB Default)? How bout ffmpeg (Default)?

[ghost]

Let me check that out, wait one

[ghost]

Yes encoding without VT, time is double however and CPU is at about 80% as expected

[ghost]

I am just using this particular system for testing so it is not a big deal right now. I just wanted to give you a heads up. No worries here anyway.

[mackworth]

Hmm. Well, I'm still hoping we can isolate this to a Handbrake problem.

Can you try one more test? To see if this is a CLI problem versus the GUI.

in Adv Prefs, Set Task's Debug level to Detail, and check Don't delete temp Files (for debug only). Then run one of the original failing downloads again. After it fails, look in the log for the relevant line starting with LaunchPath:. Cut and paste the rest of that line into Terminal.

That will invoke cTiVo's HandbrakeCLI exactly as cTiVo does it, same options, same file, etc. So I'm hoping it will give the same error message about Magic Cookie.

Be sure to turn the Don't delete option off afterwards.

If that does fail, and you're not tired of this yet, you could run that same command on a non-Sonoma system (would have to copy over the file, and adjust the paths accordingly). It would be good to know if it's introduced by that transition

Finally, all the files in the log were Get Smart; have you seen this on another channel?

[ghost]

Sono Tests Task = detailed; Delete = No

S1 = cTivo Gui S1 - com.cTiVo.cTiVo 2023-07-17--11-12-17-842.log

S2 = Handbrake CLI S2 -Terminal Saved Output.txt

Different channel / file

S3 = cTivo GUI S3 - com.cTiVo.cTiVo 2023-07-17--11-28-30-664.log

S4 = Handbrake CLI S4 - Terminal Saved Output.txt

[ghost]

Ventur Test Task = Detailed; Delete = No

V1 = cTivo GUI V1 - com.cTiVo.cTiVo 2023-07-17--12-32-38-712.log

V2 = Handbrake CLI V2 - Terminal Saved Output.txt

Different Channel / file

V3 = cTiVo V3 - com.cTiVo.cTiVo 2023-07-17--12-41-44-815.log

V4 = Handbrake CLI V4 - Terminal Saved Output.txt

[ghost]

Looks like the problem might be with calling com.apple.videotoolbox.videoencoder.ave.avc ?

[mackworth]

So, great! (at least from my point of view). It's a clearly reproducible HandbrakeCLI issue.

Only problem is that it's not only Sonoma v Ventura; it's Intel v Apple Silicon as well, obviously a big difference re hardware encoding. Do you happen to also have a Ventura Intel machine as well? I don't. If so, it'd be great to test that combo. If not, I think we have a sufficient case to submit

There's two other changes I'd like to make. You're using a custom preset (slightly different on the two machines). Also we should submit the video, so a short one would be better.

Here's a 15-second SD clip I downloaded as Decrypted. It works fine on HandbrakeCLI 1.6.1 Ventura on Apple Silicon with this simple invocation: /Applications/cTiVo.app/Contents/MacOS/HandBrakeCLI -e vt_h264 -o ~/Downloads/Grimm.mp4 -i ~/Downloads/Grimm.mpg

If it still fails on your Sonoma machine, then we're good to submit (pref with Intel-Ventura results as well). If not, then try with your custom preset to see if that fails; we'll have to isolate what change fails.

Grimm.mpg.zip Grimm-HB-Log-V-AS.txt

[ghost]

I have been digging deep into it. I reformatted the intel machine back to Ventura to see what's what. I did a total wipe-out and reinstall from web install. The problem came back at me. This might be a TiVo box / channel issue after all. I successfully used the video toolbox on 2 one hour shows each on different boxes, one Romio and one Bolt. The third Romio continues to generate the error. I am waiting to record a show from the suspect Romio. This is really perplexing. How can a TiVo box disturb the pass over? and Yet it is. Let me run a couple more test and get back to you soon.

[ghost]

Almost forgot, in an effort to remove as many wild cards as possible, I am back on the cTiVo production copy - Version 3.5.3 (1147).

[mackworth]

I would stay on 3.6, as it's the latest HandbrakeCLI. Also, there's no known problems with 3.6 at this point.

You can try using shorter records for your tests. Just change to a new channel (or else Record will back up to recent cache) and hit Record, wait a few, and then hit Record again.

The TiVo box could possibly be the problem. Obviously different channels can be (especially H.264 v Mpeg2 transport). Different machines might have different transport errors even for the same show, e.g. Signal strength or analog components might vary.

[ghost]

Yes, but that box and channel work fine on the apple silicon... That is what has me stumped. This might be just one of those things.

[ghost]

Mainstream channel downloaded and encoded fine. I guess the intel machine just doesn't like old shows. I attempted a pull down of pre 1965 shows from 2 different channels on the intel with Ventura/Sonoma and both failed. Everything else works fine.

[ghost]

I guess you might as well close this thread.

[ghost]

/Applications/cTiVo.app/Contents/MacOS/HandBrakeCLI -e vt_h264 -d ~/Downloads/Grimm.mp4 -i ~/Downloads/Grimm.mpg [18:31:11] Compile-time hardening features are enabled [18:31:11] hb_init: starting libhb thread [18:31:11] thread 7000046ae000 started ("libhb") Missing output file name. Run /Applications/cTiVo.app/Contents/MacOS/HandBrakeCLI --help for syntax.

[ghost]

Recap

Intel Sonoma and Ventura successfully downloading but failing to encode using HB custom profile only on two channels and older shows.

Apple Silicon Ventura successfully downloading and encoding these same shows using same HB custom profile presets regardless of channel or original air date.

This is repeatable but likely my individual setup.

[mackworth]

/Applications/cTiVo.app/Contents/MacOS/HandBrakeCLI -e vt_h264 -d ~/Downloads/Grimm.mp4 -i ~/Downloads/Grimm.mpg [18:31:11] Compile-time hardening features are enabled [18:31:11] hb_init: starting libhb thread [18:31:11] thread 7000046ae000 started ("libhb") Missing output file name. Run /Applications/cTiVo.app/Contents/MacOS/HandBrakeCLI --help for syntax.

Sorry, copied wrong line. Should be ‘-o’ instead of ‘-d’. Fixed above

[ghost]

/Applications/cTiVo.app/Contents/MacOS/HandBrakeCLI -e vt_h264 -d ~/Downloads/Grimm.mp4 -i ~/Downloads/Grimm.mpg [03:28:16] Compile-time hardening features are enabled [03:28:16] hb_init: starting libhb thread [03:28:16] thread 70000be13000 started ("libhb") Missing output file name. Run /Applications/cTiVo.app/Contents/MacOS/HandBrakeCLI --help for syntax. (Same result)

[ghost]

I tweaked your code slightly and this is what popped out on a successful run:

20230718-Test.txt

[ghost]

Continuing testing and I am still stumped by the state of affairs. I found the older shows fail using handbrake CLI for a custom profile using h.264 and videotool box. These same files do not fail using software encoding. I discovered today that these same files do not fail using h.265 videotool box custom handbrake profile.

[mackworth]

I think with a file that can convert in h.264 SW and h.265 HW, but fails on h.264 HW, you've narrowed it down enough to submit a report to handbrake, although a short video file would be greatly preferred. I don't know enough about the encoding process to determine if h.264/sw also looks for the magic cookie.

FYI, I found one case where someone complained about this, albeit for 4K resolution. They said turning off deinterlacing fixed it (although not a great solution for SD files).

[mackworth]

On the other permissions issues, I finally got around to downloading Sonoma. I found no problem with permissions (which should be correct; even the sandboxed thing I knew about should work as both are from he same "vendor"). Maybe it's an Intel thing, we'll find out as more folks weigh in? If you do reinstall on Intel, let me know if those recur, maybe even a screen video?

[ghost]

0I was trying to send a video (430 MB) and the profile that fails. However, GitHub has a 25mb attachment size. Any suggestion?

[mackworth]

Does it not happen with shorter size? or with the standard HW profile?

If you record a few seconds on a channel that failed, you may see the same behavior. Otherwise you can post it on a file serving site (Dropbox, etc), and just post the link.

[ghost]

https://1drv.ms/f/s!An4Bi7rRzV1Ch2QB7vnT3sFifKR8?e=XSkpjd

[mackworth]

My apologies; I've been distracted on the Intel crash problem, which is now fully resolved. Is this still an issue?

[ghost]

Me too.... I had to revert back to Ventura for many reasons. I will install it again on a M1 Max soon.

[ghost]

Back on the testing circuit. Looks like the issue of using a custom handbrake profile in cTiVo is fixed as far as I can see. No Popup when the encode phase starts.

System profile: Mac Pro Model Identifier: MacPro7,1 Enclosure: Tower Processor Name: 8-Core Intel Xeon W Processor Speed: 3.5 GHz Number of Processors: 1 Total Number of Cores: 8 L2 Cache (per Core): 1 MB L3 Cache: 16.5 MB Hyper-Threading Technology: Enabled Memory: 96 GB

[mackworth]

Thanks; good to hear. I’ll be pushing the current version shortly.