Opened 18 years ago
Closed 18 years ago
#1188 closed defect (wontfix)
Recording shows when no disk space available
| Reported by: | Owned by: | Isaac Richards | |
|---|---|---|---|
| Priority: | minor | Milestone: | unknown |
| Component: | mythtv | Version: | head |
| Severity: | medium | Keywords: | |
| Cc: | Ticket locked: | no |
Description
I couldn't find any ticket about this or similar issue and created new one.
Just found that my storage was almost full but mythbackend still started recording and died when disk became full. I know for sure that before this new LiveTV backend refused to start recording when there was enough space available. Looks like something missing with autoexpire checks or free disk space calculation doesn't work right.
I upgraded to [8821], then checked free storage space (about 1.4 GB) and started backend
cougar@zero:~> mythbackend -v record -l mythbackend.log Killed
Storage became full and because of this mythbackend exited with "Killed" message.
zero:/media/mythstorage # df .
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/vg0-mythstorage
44038844 44038844 0 100% /media/mythstorage
zero:/media/mythstorage # ls -ltr | tail -3
drwxrwxr-x 6 cougar users 3088 Feb 1 22:17 .
-rw-r--r-- 1 cougar users 36082 Feb 1 22:17 1091_20060201221500.mpg.png
-rw-r--r-- 1 cougar users 1405755392 Feb 1 22:51 1091_20060201221501.mpg
I removed some repeating errors and attach this logfile to the ticket.
Attachments (1)
Change History (5)
Changed 18 years ago by
| Attachment: | mythbackend.log added |
|---|
comment:1 Changed 18 years ago by
comment:3 Changed 18 years ago by
Any specific debuglevel that I should use here? I just tried to use gdb with [8835] (compiled with --compile-type=debug right now). I don't know how this exits but gdb doesn't give any backtrace.
cougar@zero:~> gdb /usr/bin/mythbackend -x gdbcommands GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 1101469056 (LWP 5386)] [New Thread 1106283440 (LWP 5391)] [New Thread 1108384688 (LWP 5393)] [New Thread 1110485936 (LWP 5394)] [New Thread 1112587184 (LWP 5396)] [New Thread 1114688432 (LWP 5397)] [New Thread 1116789680 (LWP 5398)] [New Thread 1118890928 (LWP 5399)] [New Thread 1120992176 (LWP 5400)] [New Thread 1123093424 (LWP 5401)] [New Thread 1125194672 (LWP 5402)] [New Thread 1127295920 (LWP 5403)] [New Thread 1131498416 (LWP 5404)] [New Thread 1133599664 (LWP 5405)] [New Thread 1136753584 (LWP 5406)] [New Thread 1138854832 (LWP 5407)] gdbcommands:6: Error in sourced command file: Couldn't get registers: No such process. (gdb) bt Cannot fetch general-purpose registers for thread 1116789680: generic error (gdb) thread apply all bt full Cannot find new threads: generic error
Anything else I can do? I don't know much about debugging threads.. ;-(
Hmm, this might be similar to [1076]. Can we get a backtrace (FAQ entry)? It's not a good thing when mythbackend crashes. I assume that this should be fixed by finding the screwed up autoexpire check or free diskspace check, but cancelling the recording and printing a logmessage is better than crashing.