Never satisfied with a solution that doesn’t include understanding what caused the problem, I googled the error message “track 1: codec frame size is not set.” This thread on superuser.com led me to a post on VideoHelp where the answer is given:
Use -acodec ac3 instead of -acodec copy it should solve your codec frame size is not set error
It works! 
I’ve updated the FAQ to reflect the current behavior.
@CycleJ - I created a work around using TagLib.DLL and Powershell running a scheduled script. When I get some free time, I’ll post the code.
I wrote a little .bat file to open the folder where ripped videos land. I typed the path into the Configuration tab Post Processing field. The field was cleared after I closed and re-opened Tablo Ripper. Is that by design?
Nope, but is your settings file still read only?
Yes. I never thought of that! I’ll unlock it and see what the code looks like, then go from there.
I typed in the path to the .cmd file and ripped three videos from Tablo to my PC. Each time a rip completed, the .cmd file was executed. I thought this only would happen once after all the rips finished. Not a big deal, but not tidy, either.
If a user wanted to post process the exported video, wouldn’t it kind of have to execute each iteration? Or after all have exported, once for each exported file?
Speculation, if you wanted something to happen after Tablo Ripper had successfully exited, run it via a script. If it puked along the way, you may not want it to happen, so you can avoid it as well.
That’s a good point. I need to get out of my box more.
Maybe they need to get out of their Windows box more
Tablo Ripper is amazingly awesome!! Sadly it’s from an era of EOL Windows version and fortunately continues to function. As Windows continues closer to SaS [Software as a Service] is may be showing it’s age after …well 7yrs is spectacular life for any Windows application, thanks to a star developer.
I had something strange happen to a recording last weekend. It is probably unrelated to Tablo Ripper but it’s worth a mention. I sent a message to Tablo support about this, but I thought it was strange enough to post here as well.
I record three one-hour programs from the same channel every weekend. The programs air back-to-back. Before last Saturday, March 11, all the recordings have been perfect. But this week, the audio and video of the first of the three programs were out of sync. In fact, the audio ran much faster than the video and ended while the video was only 45 minutes into the program. The audio track was silent for the remainder of the video.
The second and third programs were recorded perfectly, and recordings of subsequent programs were also normal and unremarkable.
Here’s why I post on this thread: I discovered the problem after I used Tablo Ripper to copy the videos to my PC. Is there any way in hell that could have corrupted one of the video files?
Thanks for reading!
When you copied the recording to your PC, did you also delete the recording on your Tablo? I’m assuming that you automatically deleted the original when you ripped it, so there is no way to check the original recording. My guess is that the original recording was in synch.
I have seen this problem before but it is always because of poor reception problems. Sometimes it can just be a small amount of pixelation, but when Tablo Ripper converts your recording to MP4, there’s a chance that the audio track will lose synch with the video.
It’s always possible for vulgar things to happen.
It’s unlikely, I recall you’re using a tablo device beyond the design of Tablo Ripper. You may have used custom ffmpeg settings and possibly had post-processing performed. So maybe.
Likely it was like that prior to exported the recording.
Beware of assumptions! I did not delete the recording on the Tablo. Playback on the Tablo and playback of the ripped MP4 file on my PC both exhibit the same issue. The original was not in sync.
Reception is great. The audio track is not just out of sync, it runs at a faster rate than the video and ends with about 15 minutes of video left.
Yes, I am using a Tablo Dual HDMI. The only change to my ffmpeg settings from the original script is to copy the AC3 audio to the rendered MP4 rather than encode it as AAC. And the only postprocessing I use is a script to open Windows Explorer in the folder where the MP4’s were saved.
If the original was not in sync, then why would you assume that Tablo Ripper had anything to do with the problem? Tablo Ripper doesn’t change the original file, it just reads the file to transcode the it to MP4.
I did not assume that Ripper had anything to do with the problem, but it is possible that it did. Because I did no’t look at the file on the TV before I transcoded it to the PC, I do not know for certain - and never will - whether the recording on the Tablo’s external drive was messed up before I opened it with Tablo Ripper.
I think we’ve beaten this horse to death. Thanks for your input.
To clarify future uncertainties Tablo Ripper, via ffmpeg streams in one direction from th drive.
Information about the recording is srored internally, so it wouldn’t mistakenly rewrite part.
That’s reassuring news. Thanks.
I had a recurrence of the problem I posted on Mar 14, only this time it affected three of the five recordings I made between 6 am 4/22/2023 and 2 am 4/23/2023. I have additional information on the possible cause: the audio packets are out of order.
The recording plays on the Tablo HDMI with the same errors I see in the ripped file, so it’s not the ripper’s fault - I guess. Would a sort step in the script prior to concatenating the files be a help?
My biggest question is, how the hell do I talk to Tablo support about this? They seem to know less about the product than anyone on this forum.
This is a screen grab of the console window displayed as the TabloRipper script ran. I reverted to the script which converts the audio to aac. The scripts which copied the ac3 audio did not display these errors.
