Clean up / purge files?

Channels DVR Server
#1

Some of my show folders in the TV folder on my hard drive seem to have episodes that I already watched and/or deleted via the app but are still on the hard drive. Is there a command I can use that cleans up the DVR folder to delete any files which are not in my queue, i.e. should have been already deleted? Or perhaps rebuilds the folder?

For example, I can see for one show I have about 150 episodes showing up in the Channels app but in the folder on my hard drive, there are close to 200 files/videos in the corresponding folder on my hard drive.

Thanks.

#2

Check the Trash on the DVR web UI or your TV

#3

There are only 8 items in my trash.

#4

Another place to check is if you have some other type of file-control on the directory. Is there some form of version control or trash feature enabled at the filesystem level for your recording directory? (This is more common for NAS/network shares, but other OS and/or filesystem level settings could impact this, too.)

#5

Not that I know of. It’s just a simple hard drive attached to my Mac. When I moved it from one computer to another, I may have chosen an old backup setting file and this newer files may have been orphaned.

#7

For each of those episodes have you selected them, and then picked the "Trash" option? Otherwise, you've merely viewed the shows, but not deleted them.

#8

I just saw that for that show, I had it set for keeping all. Duh!

But again for the other show, I have something like 150 episodes showing up but almost 200 files. I decided to delete all and start over.

#9

I discovered 1.5TB of orphaned mpg files in my secondary channels storage path. Problem was permissions, specifically, group ownership. Channels tried to delete them as they were emptied from channel's trash, but failed.

My automated migration of old recordings from SSD storage path to "overflow" HDD storage path altered the unix group (from admin to wheel, based on the default settings for macOS' launchd, I believe), which somehow prevented deletion. The channels logs were littered with "failed to delete" "permission denied" error messages, but I never looked in the logs.

My fix was recursively setting ownership to match those created by channels on the primary storage path, and changing launchd to run my migration script with the proper user:group. Once I updated the ownership, channels automatically deleted most of the files, but I had to manually delete the remainder that Channels was no longer tracking.

Just leaving this here in case anyone else suffers the same fate.

1 Like
#10

My counter to this is to ensure your permissions are correct before you try bring a foreign filesystem into a system. This is especially true across systems where UID/GIDs might not match. This is extra especially important when going from different OSes, where systems are quite different, such as Linux to BSD (macOS).

#11

My counter to this is to ensure your permissions are correct

Would be a nice thing for channels to check/notify you of if there is an issue, especially as you add new paths for it in the UI. I realize Channels is young, but long term I should never have to go to the log to get notified by something as basic as it not being able to delete a file. That should be front and center in my face (and not just on the web GUI) - at least as a notification.

#12

So, you think your software should tell you about every issue that it has because of problems you created? The software only knows what it knows; if it doesn't have the permissions to do/know something, how does it know it doesn't know? You haven't given it permission to know.

#13

So, you think your software should tell you about every issue

No, that would be absurd. However I don't think it's unreasonable to cover common use cases or easily predictable failure points. Especially since an alarming number of "solutions" to some requests in these forums are admonishment for people to just suck it up and add more storage!

Since channels DVR isn't very useful without storage, running a few checks to ensure that storage is actually useful doesn't seem like that crazy of an idea - especially on it's primary storage directory.

And I think that's the key - channels doesn't have to know the permissions - all it has to know is if the storage is useful. A simple algorithm would be, at a minimum: when either the initial or new storage is added to the DVR configuration, save a test file and delete it. If that does not work then you have just proactively caught the vast majority of possible problems someone could have around storage. If it fails, at least alert the user WHILE THEY ARE THINKING ABOUT STORAGE. Having a helpful link to troubleshooting procedures on how to potentially fix file system issues as part of the alert would be a nice bonus. Detecting the OS the server is on and automatically taking the user to the OS specific section on that help page would be nicer still.

You know, using computers to make the users life easier. A one time investment of programmer time up front creating perpetual time and frustration savings for users from then on? (and less headaches for the devs to deal with later too - its win win).

The channels DVR devs are charging money - I suspect they wouldn't mind if their userbase increased so they would get additional funds from new users. Want to make channels DVR appealing to more than just geeks/hackers? You do it with little things like this. Being proactive and not just tossing people into forums or rambling help documents (and I'm not just complaining about help documents - I'm more than willing to make suggestions/help edit if there is a way to do so. More than willing to put my money where my mouth is).

I can figure this stuff out - eventually. You obviously can. Good for us. However I want to see Channels continue to exist and heck maybe even grow. So that's why I bring up points like this - not for us, but everyone else. Maybe it's too early and the devs aren't ready yet for explosive growth - fair enough. I sure hope someone is keeping a running list of stuff like this for eventual mainstreaming of Channels - if that ever is a goal of theirs. If the only way to troubleshoot something as simple as messed up file system permissions is a bunch of manual screwing around in logs or a command line this thing is never going to get traction :stuck_out_tongue: It will remain the year of desktop linux into perpetuity.

And I know I've used applications in the past that were able to automatically fix permissions issues in folders they relied on. They may have required admin access, at least temporarily to do so, but at least someone out there figured out a way to automate it. That's the level of polish Channels needs - at least eventually - if they are interested in serving more than just us geeks.

#14

We definitely do cover common use cases and predictable failure points. So far not having write access to secondary storage is not a common failure point for folks.

The Troubleshooting tab does cover many of the common failure points and we continue to evaluate continued support requests and things we can do to notice and help people fix them.

1 Like