in my KM r5e50 box i delete files i saved to dvd.
i delete by choosing 'delete' (2x) in the blue-in-blue menu screens (after selecting the recording in the view recordings menu)

the recording disappears from the list.
when i do df after that (in a terminal screen, as a root) i find the free space got hardly more as before, in other words the hd is filling up and i don't know what is doing this (apart from the recordings i have to edit yet, and the log files of 'operations done', which i believe cannot be gigabytes big... (the logs))

anyone who can help here??

tx

There's a couple of possibilities here, Are you sure you're running the df correctly? -- Without parameters it lists the space on all volumes making it easy to look at the wrong partition. I prefer to 'cd' into the /myth/tv directory and run 'df -k .' The -k presents results in kb, the dot restricts output to "the partition containing the current directory"

By default KM configures myth to put recordings on a different partition from your logs, so it's not likely that logs are skewing your results, and as you point out log files are not in the same size ballpark as recordings.

The other things to look at:
1. Did the recordings actually delete? permission errors can cause the gui to take the files off the list without actually deleting the file.
2. There is a setting somewhere that stops myth from deleting the source file after transcoding, maybe this is set?
3. There's another setting that causes myth to delete files slowly. (This is a good thing for some file system types) If this is set you may need to wait a few minutes between selecting delete, and checking your disk space.

Finally look over the 'du' command. Like 'df' it tells you about disk usage, but 'du' can get down to the file and directory level, which gives you finer control when looking for space wasters. 'df' is much faster than 'du' but only gives you the summary report; no detail.

thank you *very* much for your answer!

when i am in /myth and logged in as root,
i do 'df'
the output is:
/dev/hda1 ; 1K blocks ## ; used ## ; available ## ; use % ## ; mounted on /
/dev/hda3 ; 1K blocks ## ; used ## ; available ## ; use % ## ; mounted on /myth
tmpfs ; 1K blocks ## ; used ## ; available ## ; use % ## ; mounted on /dev/shm

(## are actual sizes)

when i do 'df -k' on the same place, result is the same.

actually i used to do the 'df' (or 'df --block-size=M') in /myth/tmp/work , as after prepairing for archive the files (vob, and iso) appeared to be in this directory.
i used to delete the contents of 'myth/tmp/work' and 'myth/tmp/work/dvd/VIDEO_TS' after each successfull archiving (to my dvd-disk).

in /myth/tmp/work there are dir's 1,2,3,4 and 5, and dvd too.
i supposed the big files in 1 and 2 (present today) could be deleted and this has just now freed up some useful space.

when i look in /myth/tv , there is a BIG bunch of *.mpg (big) and .mpg.png files (smaller)
as the files have a name made of recording data (date, time) i cannot easy compare with the recordings-listing in the blue-in-blue screen menu (to look if some of them should be deleted), so i cannot give info on this that fast.

Are you saying that "df" is returning "##" instead of numbers? I've never seen that happen before.



The ".mpg" files are the recordings; the ".png" files are thumbnails. A quick way to check for consistency between the database and the /myth/tv directory is to compare the count of the number of recordings to the number of *.mpg files. As root:


The first number reported is the number of .mpg files. If you use mythweb, it will report the number of recordings in the database at the bottom of the "recorded programs" screen. If the 2 numbers do not match, you have a consistency issue.

Marc

no, i must have been confusing (Xcuse me)..
there are real numbers on the locations marked by ##, i thought the real size was irrelevant to the question and was too lazy to type them


the system does return:

so there appear to be 3 numbers, but there is no match

I think you mis-interperted my original post -- you need to compare the first number (73) to the number of recordings reported by mythweb.

Marc

the numbers match, must be good

That's my thought as well. When using the slow delete (which keeps your system from stuttering while it deletes), it can take a while. If I delete a bunch of recordings at once, I know not to look at the space until the next day.

the deleting is that slow the machine has the space freed only a day later (and has been running (=on) all the time??

when that's the case i would be better off to uncheck the 'slow' setting, while -in my way to use the box- am only recording OR deleting, but not at the same time..

maybe the setting 'slow' is for boxes running 24/7 and recording all the time and deleting automatically due to the expiration pointer.
(that's not the way I use the box)

1) Possibly slow delete. It shouldn't be _THAT_ slow however, say 10 minutes tops. if you're deleting dozens or scores of files maybe an hour.

2) If something else has the file open, the space won't show up as recovered until it's closed.