Ffprobe: no such file or directory

Channels DVR Server
#1

I stumbled upon an unexpected issue today. I just wanted to document it in case anyone else runs into it.

I am running Channels DVR from a docker container running on UnRaid. Today I replaced my cache drive. As part of this process, I backed up my appdata folder which contains the settings for all of my Docker containers including Channels DVR. Once I replaced the cache drive, I restored appdata including the Channels DVR settings. Everything worked as expected until I decided to take a look at View Detail from a TV episode that I recorded on the DVR. When I tried to look at View Detail, I got the following error message:

Error retrieving file #12705details: fork/exec /channels-dvr/2024.09.24.1553/ffprobe: no such file or directory

I took a look inside the appdata/ChannelsDVR folder and sure enough there was a 2024.09.24.1553 folder, but it was empty. However, there was also a 2024.09.10.2115, but instead of being empty, there were several binary files including ffprobe.

After some additional digging and testing, I remembered that I had updated to a pre-release version of Channels DVR a week or two before replacing the cache drive. I decided to update to the latest pre-release and then checked my appdata/ChannelsDVR folder. Sure enough I had a new folder 2024.10.01.1128 with binaries in it. I then went back into Channels DVR and selected More Info on the episode and this time it worked! I no longer had the error message.

Honestly, I am not sure if this issue was present before I swapped the cache drive, or if it was a result from something that occurred during replacing the cache drive and the backup/restore. For the record, I used the Appdata Backup plugin from KluthR's repository to perform the backup and restore.

Just sharing in case anyone else ever runs into this issue.

#2

Probably something wrong with that backup/restore and symbolic links.
Channels DVR creates a symlink named latest that points to the latest version directory it downloaded.
So that symlink should have been pointing to the directory 2024.09.24.1553 when you backed up.

#3

Good to know. I was actually going to manually copy the binaries over to the empty folder but then got the idea to update to the latest pre-release. That may have seen there wasn't the link so created it? What gave me the idea to update to the latest pre-release was that the older folder had the binaries instead of the newer one, but now it makes sense why it didn't.

#4

Every time you update, CDVR downloads the latest executables into a folder named for the version number, then creates the directory symlink latest that points to that folder.

(A bit off-topic, but you can change that symlink to point to an earlier version on your disk and run it)

#5

Ah yes taking a look at the ChannelsDVR folder in appdata and I see the latest folder with the binaries in it.

#6

The other possibility is that "cache" drive you replaced was where the DVR executables were.
Do you know what the volume mappings are for your Channels DVR docker container?
Maybe using /mnt/user/appdata/ChannelsDVR

Either way, it sounds like the backup/restore didn't work right.

#7

I purposely point directly to /mnt/cache/appdata for performance reasons. Everything else restored fine. I took a look at the Appdata Backup forums and saw one or two other posts in there regarding problems with symbolic links, so that most likely was the issue.

1 Like
#8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.