Linda Walsh composed on 2016-03-11 18:40 (UTC-0800): Thanks much for the reply Linda! :-)
Your numbers don't add up. You are saying the recordings are truncating @ ~13M, but the disk has about 25383M (or 24G) free. I.e. out of 2048G, you have 24G free when you start -- that would be slightly 1% of free space. Most OS's won't allow you allocate more than 90-95% -- you have less than 1.2% free which is *horrible*. For my busy disks, I try to always keep freespace >20-25%, but even on disks infrequently written to, I try not to go over 80-85% usage. Second bit about your numbers. Even though you have 24G free, you are saying your files stop recording at about 5-6% of that.
The current situation is complicated by unforeseen consequences tangling with foreseeable consequences and snowballing. I would have plenty of freespace if I could ever find a video editor that works to free up the 31% of space wasted by commercials. Gobs of time has been wasted trying to work around the consequences. These STBs do not provide support for filesystem sizes that >2TB disk sizes and GPT offer. And, they don't come with a full complement of the tools Linux users are used to having at their disposal. Time keeps disappearing at obscene rates trying to cope. I know we don't want filesystems with nearly zero freespace, but here there just no way around that in the foreseeable future. Adding space means piling complications on top of complications WRT not only the STB's storage, but also the backup/restore situation. These STBs make backup/restore a horribly tedious and lengthy process, not to mention keeping track of what is to be found where. I need to know how much of the space I see free that I can use. 98%-99% was temporary as a result of trying to figure out the hard way how much could be used, making recordings until the machines refused to make any more, but stopping making them while freespace is available many times the size of typical recordings smells like some other problem is involved. My current thinking is that the multiplicity of test recordings named *instant record.ts is proving to be yet another complication and shortcoming of the STB software. If numbers don't add up, it's on account of mixup between different tools, nada vs. K vs. M vs. G vs. T., cmdline vs. mc, etc. Maybe this will help: # df -h /dev/sda1 Filesystem Size Used Available Use% Mounted on /dev/sda1 1.8T 1.7T 75.4G 96% /media/wd20azbme2t # ls -lrth *.ts | tail -n7 2.4G Dec 24 17:29 bigBang0711-201512241700GDMX10wd.ts 2.4G Jan 29 18:29 bigBang0516-201601291800GDMX10we.ts 3.0G Feb 7 17:59 bigBang0510-201602071730GDMX10wd.ts 3.1G Feb 14 17:59 bigBang0516-201602141730GDMX10wd.ts 2.7G Mar 4 17:59 bigBang0705-201603041730GDMX10we.ts 1.0G Mar 11 22:00 20160311 2145 - GDMX09EV - instant record.ts 1.9G Mar 11 22:29 20160311 2200 - GDMX09EV - instant record.ts
If those numbers are real -- what rate are you recording?
Modest for HD source, usually less than 5M/hour.
...Your application may even be at fault, maybe writing the recordings to a temporary file before writing them to the final destination...
I've been unable to find any evidence of use of temporary files WRT recording.
consuming, say 5MB/s, the OS might not be able to keep up and end up returning "no space" before you've actually run out of space -- or it may be your application is unable to buffer enough space before the OS returns from a write call -- and your application aborts the recording when it realizes it "lost" part of the recording.
Many attempts to record, according to filenames and timestamps, have aborted within a minute of start. However I believe what is happening is that the #####K files are all the result of the STB first creating a many times larger recording, then cutting off a huge tail. UI behavior is different for recordings that do not get truncated vs. those that do. Hitting the stop button on whole recordings returns the UI to ready state instantly. With those truncated, UI displays a busy indicator for a considerable period instead. AFAICT, there is no "user" in the system. Everything WRT recording, and elsewhere, seems to be owned by root.root. /dev/sda1 is internal, data use only (recordings, settings backups, and my own backups of various configs). The last 3 recordings, all made after deleting the multiplicity of test recordings, and bringing freespace back to 96%, have completed normally, so I seem to be back to trying to figure out exactly how much space can actually be used. Many times on Linux PCs I've found it possible to get df to show 0% free on / without the system locking up, at least, before systemd and journald usurped predictable, tried and true. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org