New Feature: Safer deleting with Trash

Devs can chime in if I’m wrong but I believe the short answer is “No.”

No, we don’t have a way to re-import TV Shows at this point.

If you have no way to import them back in can we have an option to disable this feature ... my Synology already takes care of deleted files no need for redundancy.

From the web UI, under Recordings > Recordings > Trash, each deleted program has a "Recover" and "Delete Now" button. If you press "Recover", the program is added back to the database, and will appear in the clients as if nothing happened. If you press "Delete Now", it will function just like deleting a recording used to work.

The Trash feature does not delete the program immediately; it is left in place.

I believe the above question about adding deleted metadata back into the database was in reference to adding programs back using the "Import" feature, not when using "Restore" on a recording in the Trash.

2 Likes

Got it thanks ... I like it ... will disable the Synology Trash can on my Recording Channels Folder.

1 Like

Thank you for the quick reply.

So, i have recordings that did not delete after the 7 days. One from the 29th still remains in it folder

I go to the DVR Trash page on wht web ui and get a huge error page javscript thing and the page flashes, then browser crashes.

EDIT: updateing to 2020.02.06.0011 and the page works again.

Yes the latest update fixed the issue.
I too still show recordings from 1/29/2020. It says "Scheduled to be removed soon"

2/6/2020 Update:
Recordings from 1/29/2020 have now been deleted

1 Like

My DVR stopped during a processing commercials to a recording that I manually deleted it from the trash. DVR would not restart automatically. So it appears that you can not delete the recording from trash until processing is completed. Here is the log of the recording deleted.
2020/02/08 17:45:52.163788 [DVR] Deleting /volume1/DVR/TV/XFL Football/XFL Football Seattle Dragons at DC Defenders 2020-02-08-1259.mpg
[GIN] 2020/02/08 - 17:45:52 | 200 | 125.499249ms | 97.82.66.41 | PUT /dvr/files/3114/permanently_delete
[GIN] 2020/02/08 - 17:45:52 | 200 | 225.091358ms | 97.82.66.41 | GET /dvr/files?all=true
[GIN] 2020/02/08 - 17:45:52 | 200 | 212.743366ms | 97.82.66.41 | GET /dvr/recordings/summary
[GIN] 2020/02/08 - 17:45:53 | 200 | 34.864141ms | 97.82.66.41 | GET /dvr/groups
[GIN] 2020/02/08 - 17:45:53 | 200 | 48.140389ms | 97.82.66.41 | GET /dvr/recordings/upnext
[GIN] 2020/02/08 - 17:45:53 | 200 | 342.506775ms | 97.82.66.41 | GET /dvr/groups/movies/files
[GIN] 2020/02/08 - 17:45:53 | 200 | 140.711191ms | 192.168.1.9 | PUT /dvr/files/3116/playback_time/5863
[GIN] 2020/02/08 - 17:45:53 | 200 | 626.025µs | 97.82.66.41 | GET /dvr
[GIN] 2020/02/08 - 17:45:53 | 302 | 58.427µs | 97.82.66.41 | GET /favicon-32x32.png
[GIN] 2020/02/08 - 17:45:53 | 302 | 39.235µs | 97.82.66.41 | GET /apple-touch-icon.png
[GIN] 2020/02/08 - 17:45:53 | 302 | 149.187µs | 97.82.66.41 | GET /oauth/start/auto
[GIN] 2020/02/08 - 17:45:53 | 200 | 444.551µs | 97.82.66.41 | GET /troubleshoot
[GIN] 2020/02/08 - 17:45:53 | 302 | 73.687µs | 97.82.66.41 | GET /oauth/start/auto
[GIN] 2020/02/08 - 17:45:53 | 200 | 2.989016ms | 97.82.66.41 | GET /system
[GIN] 2020/02/08 - 17:45:53 | 200 | 420.659µs | 97.82.66.41 | GET /remote
[GIN] 2020/02/08 - 17:45:53 | 200 | 683.296µs | 97.82.66.41 | GET /dvr/scanner/paths/movies
[GIN] 2020/02/08 - 17:45:53 | 200 | 3.39234ms | 97.82.66.41 | GET /settings
[GIN] 2020/02/08 - 17:45:53 | 200 | 321.056µs | 97.82.66.41 | GET /updater
[GIN] 2020/02/08 - 17:45:53 | 200 | 660.916µs | 97.82.66.41 | GET /dvr
[GIN] 2020/02/08 - 17:45:53 | 200 | 3.371526ms | 97.82.66.41 | GET /bonjour
[GIN] 2020/02/08 - 17:45:53 | 200 | 1.68002ms | 97.82.66.41 | GET /remote/nat
[GIN] 2020/02/08 - 17:45:53 | 200 | 5.732402ms | 97.82.66.41 | GET /devices
[GIN] 2020/02/08 - 17:45:53 | 200 | 614.317µs | 97.82.66.41 | GET /dvr/lineups
[GIN] 2020/02/08 - 17:45:53 | 200 | 607.26µs | 97.82.66.41 | GET /dvr/lineups
[GIN] 2020/02/08 - 17:45:54 | 302 | 50.056µs | 97.82.66.41 | GET /favicon-16x16.png
[GIN] 2020/02/08 - 17:45:54 | 302 | 69.331µs | 97.82.66.41 | GET /oauth/start/auto
[GIN] 2020/02/08 - 17:45:59 | 200 | 150.035172ms | 192.168.1.9 | PUT /dvr/files/3116/playback_time/5869
[GIN] 2020/02/08 - 17:46:00 | 200 | 59.424029274s | 97.82.66.41 | GET /dvr/events/subscribe
[GIN] 2020/02/08 - 17:46:05 | 200 | 116.523886ms | 192.168.1.9 | PUT /dvr/files/3116/playback_time/5875
[GIN] 2020/02/08 - 17:46:11 | 200 | 155.957012ms | 192.168.1.9 | PUT /dvr/files/3116/playback_time/5881
[GIN] 2020/02/08 - 17:46:17 | 200 | 138.912849ms | 192.168.1.9 | PUT /dvr/files/3116/playback_time/5887
[GIN] 2020/02/08 - 17:46:23 | 200 | 127.944234ms | 192.168.1.9 | PUT /dvr/files/3116/playback_time/5893
[GIN] 2020/02/08 - 17:46:29 | 200 | 203.362003ms | 192.168.1.9 | PUT /dvr/files/3116/playback_time/5899
[GIN] 2020/02/08 - 17:46:35 | 200 | 146.374379ms | 192.168.1.9 | PUT /dvr/files/3116/playback_time/5905
[GIN] 2020/02/08 - 17:46:41 | 200 | 217.594763ms | 192.168.1.9 | PUT /dvr/files/3116/playback_time/5911
[GIN] 2020/02/08 - 17:46:47 | 200 | 119.562386ms | 192.168.1.9 | PUT /dvr/files/3116/playback_time/5917
[GIN] 2020/02/08 - 17:46:53 | 200 | 166.753664ms | 192.168.1.9 | PUT /dvr/files/3116/playback_time/5923
[GIN] 2020/02/08 - 17:46:59 | 200 | 131.573674ms | 192.168.1.9 | PUT /dvr/files/3116/playback_time/5929
[GIN] 2020/02/08 - 17:47:05 | 200 | 117.965726ms | 192.168.1.9 | PUT /dvr/files/3116/playback_time/5935
[GIN] 2020/02/08 - 17:47:11 | 200 | 134.01086ms | 192.168.1.9 | PUT /dvr/files/3116/playback_time/5941
[GIN] 2020/02/08 - 17:47:17 | 200 | 153.646829ms | 192.168.1.9 | PUT /dvr/files/3116/playback_time/5947
[GIN] 2020/02/08 - 17:47:23 | 200 | 171.686587ms | 192.168.1.9 | PUT /dvr/files/3116/playback_time/5953
2020/02/08 17:47:24.269501 [DVR] Commercial detection failed with exit status 103
2020/02/08 17:47:24.269610 [IDX] Generating video index for file-3114: XFL Football Seattle Dragons at DC Defenders 2020-02-08-1259.mpg
2020/02/08 17:47:24.292207 [ERR] Generating video index for file-3114 failed: Couldn't open file: /volume1/DVR/TV/XFL Football/XFL Football Seattle Dragons at DC Defenders 2020-02-08-1259.mpg: open /volume1/DVR/TV/XFL Football/XFL Football Seattle Dragons at DC Defenders 2020-02-08-1259.mpg: no such file or directory
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xc67a28

Were there any more lines after this?

dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xc67a28]

goroutine 89 [running]:
github.com/fancybits/channels-server/dvr.(*File).Refresh(...)
github.com/fancybits/channels-server@/dvr/file.go:136
github.com/fancybits/channels-server/dvr.(*Recorder).RunProcessor(0xc00000c3c0)
github.com/fancybits/channels-server@/dvr/recorder.go:374 +0xa18
created by github.com/fancybits/channels-server/dvr.(*Recorder).Run
github.com/fancybits/channels-server@/dvr/recorder.go:168 +0xa9
2020/02/08 17:52:27.319790 [SYS] Starting Channels DVR v2020.02.07.0409 (linux-x86_64 pid:20876) in /volume1/@appstore/ChannelsDVR/channels-dvr/data
2020/02/08 17:52:27.792050 [HDR] Found 1 devices
2020/02/08 17:52:30.554530 [SYS] Started HTTP Server
2020/02/08 17:52:33.033364 [DVR] Recording engine started in /volume1/DVR
2020/02/08 17:52:33.034331 [SYS] Bonjour service running for dvr-kwbjr_server.local. [192.168.1.24]
2020/02/08 17:52:33.134954 [DVR] Starting job 1581199140-135 XFL Football on ch=[6.1]
[GIN] 2020/02/08 - 17:52:33 | 200 | 1.336159ms | 192.168.1.9 | GET /status
2020/02/08 17:52:33.582737 [TNR] Opened connection to 107104F1/0 for ch6.1 WBRC
2020/02/08 17:52:33.582860 [DVR] Recording for job 1581199140-135 from 107104F1 ch6.1 into "TV/XFL Football/XFL Football Los Angeles Wildcats at Houston Roughnecks 2020-02-08-1559.mpg" for 2h7m26.864926346s
2020/02/08 17:52:33.596084 [DVR] Starting job 1581201240-ch6753 The Chamber (1996) on ch=[6753]
2020/02/08 17:52:33.596144 [DVR] Waiting 19h6m26.403862263s until next job 1581274740-135 XFL Football
[GIN] 2020/02/08 - 17:52:33 | 200 | 1.190951ms | 192.168.1.9 | GET /auth
[GIN] 2020/02/08 - 17:52:33 | 200 | 5.37906ms | 192.168.1.9 | GET /dvr
[GIN] 2020/02/08 - 17:52:33 | 200 | 257.239788ms | 192.168.1.9 | GET /dvr/rules
[GIN] 2020/02/08 - 17:52:33 | 200 | 309.738323ms | 192.168.1.9 | GET /dvr/jobs
[GIN] 2020/02/08 - 17:52:34 | 200 | 49.044655ms | 192.168.1.9 | GET /dvr/groups
[GIN] 2020/02/08 - 17:52:34 | 200 | 31.096896ms | 192.168.1.9 | GET /dvr/programs
[GIN] 2020/02/08 - 17:52:34 | 200 | 835.971582ms | 192.168.1.9 | GET /dvr/files
[GIN] 2020/02/08 - 17:52:34 | 200 | 43.45381ms | 192.168.1.9 | GET /dvr/recordings/upnext
2020

From what I can see you ran into an issue that is unrelated to deleting. It just happened to occur at around the same time. Thanks for the report.

Please update to the latest DVR beta. It should resolve this issue.

What happens if you run low on Space is Channels DVR smart enough to delete from this trash folder to record new episodes ?

1 Like

No, it doesn't currently take that into account. How much free disk space would you want to keep available?

Currently none of our deletion logic takes into account available disk space and it hasn't been something that most of our customers have had a need for at this point.

Do you often run low on disk space on your DVR?

I believe this was previously discussed but the option to delete recordings after X number of days might solve this problem. For me personally, delete after 1 day will suffice

1 Like

I don't currently have any space issues, but I also don't know why I would need a deleted program for a full 7-days. I think 99% of my restore program needs would be on a program I accidentally deleted (so I would know immediately). I guess it's possible that another household member deletes a show and I might not notice for a few days? In that case, keeping it around longer isn't necessarily a bad thing.

Being able to custom define the length would make it more flexible for those who don't want to use up the space.

I would prefer to define the amount of space reserved for the deleted items. For example, if I reserved 150GB of space for deleted items, it would just save the recordings indefinitely until that limit is reached. Once the limit was reached, it would prune the oldest programs. Not sure if this would create other potential issues though.

mmm Maybe an Option to disable this feature ... I just do not like having deleted recordings taking up space and not be able to use that space when needed without manually doing something. ... I think I prefer going back to my regular Synology trash bin. I usually binge watch and delete full seasons.

Right now I have over 100 Episodes deleted but no space freed.

2 Likes

I've just released v2020.02.14.0245 that adds an option for specifying how long to keep recordings in the Trash before deleting them. To be the safest the default is 10 days.

4 Likes

Awesome. Thank you.

1 Like