working on the MythTV pi2

A while back I got MythTV running on the Pi2 again (I have a pi3 but the HDMI doesn’t work).

the symptom

Yesterday I was recording a 1080p OTA broadcast and the recording suddenly failed. I looked at the filesize: 4GB. Oh.

the problem

The SSD in question had been used on the cheapo Homeworx DVR and was formatted as FAT32 for that device. There is a 4GB filesize limit on FAT32 but the Homeworx just stopped at that point and started a new file for the recording. MythTV doesn’t do that so the recording just stops.

the fix

So I need a filesystem that will handle >4GB. But there are about 350GB of OTA recordings, movies, and videos on the SSD. I don’t have enough room on my laptop drive to hold it, and my other spare SSD is only 128GB. Hmmmm.

Wait! I have a 4TB honest-to-doG spinning drive in a USB enclosure I use for backups.

1. mount the 4TB
2. move the SDD data to the 4TB (took half the night, I went to bed)
3. reformat the SSD partition to ext2¹
4. move the 4TB data back to the SSD (woke up in the middle of the night to start this, finished by morning)

It worked, but I rebooted the pi the next day and it bootlooped. I made a typo in the /etc/fstab. Pulled the card, mounted on the laptop, fixed the fstab and we’re running again. If I had been rested a sudo mount --all would have alerted me to the error.

addendum: seektables

With this instance I’ve had problems with seeking (FF/RW, time estimates) being off. Maybe the software changed, or maybe the volume normalization is causing weirdness. Some google-fu suggested the fix was rebuilding the seektables with:

mythcommflag --file {/path/to/file} --rebuild

Normally the program does commercial detection and flagging but with the --rebuild switch it just does makes sure the file and the database agree on things.

test run

automated processing

I added the seektable rebuild to the backend recording processing script

Wed 18 Oct 2023 05:31:47 PM MDT
 342050772 10403_20231018230000.ts <- unmolested file
480, will process <- not HD, will process
 422131252 10403_20231018230000.ts-TEMP.ts <- normalized and error-cleaned
rebuilding seek table for 10403_20231018230000.ts <- the seeky stuff
Wed 18 Oct 2023 05:34:32 PM MDT
END

So the little-Pi-that-could did all the crunching on a half-hour 480p recording at nice -19 priority in about 3 minutes. Hard to complain about that.

I skip processing of 720 and 1080 recordings since the overloaded pi2 (combo frontend/backend!) can’t play those back reliably and do everything else at the same time. I stream those over wifi to tablet, laptop, or phone. Since they aren’t being processed they don’t need the seek repair, either.

1542043304 11901_20231018025900.ts
1080, skipping
END

That HD recording was 1.54GB for a half-hour.

manual correction of existing recordings

I ran the rebuild on all the other ~180 recordings overnight.

update: the payoff

[Oct 22] got my first >4GB recording today, an ~8GB figure skating broadcast.

1. I didn’t want journaling. I think the correct approach would have been to format to ext4 with journaling disabled, but it was late and I was tired. IIRC ext2 can be migrated to ext4 later without reformatting. ↩