LinHES Forums :: View topic - Are my HDs dying / I can't backup

LinHES Forums http://forums.linhes.org/

Are my HDs dying / I can't backup http://forums.linhes.org/viewtopic.php?f=5&t=13427	Page 1 of 2

Author:	jmacmythtv [ Wed Jan 10, 2007 8:43 pm ]
Post subject:	Are my HDs dying / I can't backup
Hi all, Went to use my mythbox after ages of good use and it was reacting very slowly. Live TV would throw me back to menu and recordings was empty. There was lots of free disk space on my lvm - no massive sql.logs. I found this in the kern.log: Jan 10 00:49:49 myvcr kernel: ivtv0 warning: ENC: (0) DMA Error 0x0000000b Jan 10 00:49:52 myvcr kernel: ivtv0 warning: ENC: REG_DMAXFER 2 wait failed Jan 10 00:49:58 myvcr kernel: ivtv0 warning: ENC: DMA still Pending while stopping capture! Jan 10 19:41:07 myvcr kernel: ivtv1: Cause: the application is not reading fast enough. Jan 10 19:41:32 myvcr kernel: ivtv1: All encoder MPEG stream buffers are full. Dropping data. Jan 10 19:41:33 myvcr kernel: ivtv1: Cause: the application is not reading fast enough. Jan 10 19:42:02 myvcr kernel: ivtv1: All encoder MPEG stream buffers are full. Dropping data. Jan 10 19:42:02 myvcr kernel: ivtv1: Cause: the application is not reading fast enough. After a bunch of troubleshooting, I restarted the backend and things seem to be back to normal. My first though was to backup ... which I did from the menu (r5d1). The savedfiles looks OK but the mythconverg.sql is 0 bytes. Oddy, the checkbackup.sh spits out ERROR 1045: Access denied for user: 'root@localhost' (Using password: NO) then tells me it passes all tests .... so ... looking for thoughts on the errors above and a way to be sure I have a good backup. tia Oops ... posted in the wrong forum ... anyway to move these?[/list]

Author:	evdogg [ Wed Jan 10, 2007 9:45 pm ]
Post subject:
I think the ivtv errors are a PCI latency issue, at least that second grouping about not reading data fast enough. Check this entry on the MythTV.org wiki for an explanation and a possible fix.

Author:	tjc [ Wed Jan 10, 2007 10:10 pm ]
Post subject:
It mostly looks like your DB, or access to it, is hosed. I should add something to the backup checks that no records found in the DB is a failure condition...

Author:	jmacmythtv [ Thu Jan 11, 2007 7:16 am ]
Post subject:
Thanks guys. Don't think that it is related to PCI latency as the system was working quite well for a while. Also, the system was virtually idle at the time of the errors. Unless these settings are dynamic?? On the backup side, the empty sql file was produced after the system resumed normal operation - I could access, watch, and manage my recordings - wouldn't that mean that the db was accessible? I also noticed that the backup script now creates files that are 600 root:root instead of 600 mythtv:mythtv. I originally thought that the access denied error was a result of this ... but after changing them found out it was not (besides, the access denied error looks like mysql due to the "using password" part.) As per the subject of the post, I am kind of leaning towards a dying HD ... would this make sense? Any recommendations for disk checking utilities? Smart is not on my HDs. thanks!

Author:	tjc [ Thu Jan 11, 2007 7:23 pm ]
Post subject:
Have you monkeyed with the DB at all? Changed passwords, set up access for a remote front end, ...?

Author:	jmacmythtv [ Thu Jan 11, 2007 8:04 pm ]
Post subject:
No sir ... none of the above. I did have ~95 episodes of seinfield that I decided to reduce. I started deleting through the front end and then decided that it was faster on mythweb .. so I switched. Don't think that this could be related. Having said that, I was suprised that I haden't freed up more space at the end of this process. Is there a way that the actually video files can get out of sync with their info in the db?

Author:	jmacmythtv [ Thu Jan 11, 2007 8:08 pm ]
Post subject:
Oh .. the other thing that I have done recently for the first time is trying to create cutlist for some recordings. I edited the videos, fine tuned the commercial flag points, then asked the machine to transcode them ... They are red in the job queue - errored immediately after the process started. I wasn't sure where to look for the debug info on this.

Author:	tjc [ Thu Jan 11, 2007 8:45 pm ]
Post subject:
jmacmythtv wrote: Is there a way that the actually video files can get out of sync with their info in the db? Uh, yeah. Pretty much exactly what you described doing. The entry in the DB is just a reference to the actuall files. The application normally does the work to keep them in sync but errs to the side of safety. It was taking time to remove them because deleting big files requires a certain amount of work... I really don't want to think about what state your DB is in after all that fooling around, so I'm going to jam my fingers in my ears, sing "La-la-la-I-can't-hear-you-la-la-la!!!" loudly and wander off to do something else until my stomach settles.

Author:	jmacmythtv [ Thu Jan 11, 2007 9:15 pm ]
Post subject:
oops ... any chance that I get can things in sync again ... or is the system a write-off?

Author:	jmacmythtv [ Fri Jan 12, 2007 6:42 pm ]
Post subject:
So I compared my myth/tv/ folder with the "recorded" dbase and there were 3 extra items in the db that should not have been there. I deleted these through the front end. No help though. While continuing my troubleshooting I noticed that my memory usage was at 97% (of 1GB) ... the last time I had checked this it was always very low - to the point where the swap wasn't even being used. So I decided to reboot but I ended up with a kernel Oops (errors below for those interested) and the system wouldn't go down nicely. After lengthy deliberation, I forced it down. To my suprise, it came back up without any compaints and now it appears to be behaving normally (I can watch live tv and record) However, my .sql backup still ends up empty ... not a good thing if I want to update. Any thoughts would be appreciated however, I think a new thread might be in order. Thanks! kern.log errors on attempted shutdown: Broadcast message from root (ttyp0) Fri Jan 12 19:09:33 2007... The system is going down for reboot NOW !! root@myvcr:/myth/tv# Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: Oops: 0000 [#1] Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: Oops: 0000 [#1] Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: PREEMPT SMP Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: PREEMPT SMP Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: CPU: 0 Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: CPU: 0 Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: EIP is at snd_cx88_capture_volume_get+0xb/0x30 [cx88_alsa] Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: EIP is at snd_cx88_capture_volume_get+0xb/0x30 [cx88_alsa] Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: eax: 00000000 ebx: 00000000 ecx: f4d05cc0 edx: f7b94800 Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: eax: 00000000 ebx: 00000000 ecx: f4d05cc0 edx: f7b94800 Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: esi: 00000001 edi: 00000000 ebp: f7b6f000 esp: d79f5f04 Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: esi: 00000001 edi: 00000000 ebp: f7b6f000 esp: d79f5f04 Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: ds: 007b es: 007b ss: 0068 Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: ds: 007b es: 007b ss: 0068 Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: Process alsactl (pid: 17631, threadinfo=d79f4000 task=c193b550) Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: Process alsactl (pid: 17631, threadinfo=d79f4000 task=c193b550) Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: Stack: f92b5828 f4d05cc0 f7b94800 f4d05cc0 f7b6f14c bffe8a50 00000003 00000000 Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: Stack: f92b5828 f4d05cc0 f7b94800 f4d05cc0 f7b6f14c bffe8a50 00000003 00000000 Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: f7b94800 f7b6f1e8 f7b6f000 f92b5891 f7b6f000 f7b94800 ffffffe7 f7129f00 Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: f7b94800 f7b6f1e8 f7b6f000 f92b5891 f7b6f000 f7b94800 ffffffe7 f7129f00 Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: bffe8a50 c2c45512 c0182fbc f7b6f000 bffe8a50 bffe8a50 f7129f00 bffe8a50 Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: bffe8a50 c2c45512 c0182fbc f7b6f000 bffe8a50 bffe8a50 f7129f00 bffe8a50 Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: Call Trace: Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: Call Trace: Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: <f92b5828> snd_ctl_elem_read+0xe8/0xf0 [snd] <f92b5891> snd_ctl_elem_read_user+0x61/0xb0 [snd] Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: <f92b5828> snd_ctl_elem_read+0xe8/0xf0 [snd] <f92b5891> snd_ctl_elem_read_user+0x61/0xb0 [snd] Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: <c0182fbc> do_ioctl+0x5c/0x70 <c0183143> vfs_ioctl+0x53/0x1c0 Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: <c0182fbc> do_ioctl+0x5c/0x70 <c0183143> vfs_ioctl+0x53/0x1c0 Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: <c018330d> sys_ioctl+0x5d/0x70 <c0103177> syscall_call+0x7/0xb Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: <c018330d> sys_ioctl+0x5d/0x70 <c0103177> syscall_call+0x7/0xb Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: Code: 00 00 c7 40 50 00 00 00 00 c7 40 54 3f 00 00 00 31 c0 c3 8d b6 00 00 00 00 8d bc 27 00 00 00 00 8b 44 24 04 8b 54 24 08 8b 40 5c <8b> 00 8b 40 38 8b 80 94 05 32 00 83 f0 ff 83 e0 3f 89 42 44 31 Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: Code: 00 00 c7 40 50 00 00 00 00 c7 40 54 3f 00 00 00 31 c0 c3 8d b6 00 00 00 00 8d bc 27 00 00 00 00 8b 44 24 04 8b 54 24 08 8b 40 5c <8b> 00 8b 40 38 8b 80 94 05 32 00 83 f0 ff 83 e0 3f 89 42 44 31 Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: EIP: [pg0+953756139/1066120192] snd_cx88_capture_volume_get+0xb/0x30 [cx88_alsa] SS:ESP 0068:d79f5f04 Message from syslogd@myvcr at Fri Jan 12 19:09:40 2007 ... myvcr kernel: EIP: [pg0+953756139/1066120192] snd_cx88_capture_volume_get+0xb/0x30 [cx88_alsa] SS:ESP 0068:d79f5f04

Author:	tjc [ Fri Jan 12, 2007 7:53 pm ]
Post subject:
Try doing the DB dump manually. The relevant bit form the backup script is: Code: /etc/init.d/mythtv-backend stop # Stop, check, and fix $DATABASE db to ensure clean copy, then restart it. /etc/init.d/mysql stop cd $DATABASE_DIR myisamchk -f *.MYI /etc/init.d/mysql start # Dumps the $DATABASE database mysqldump -c -u root $DATABASE > $BACKUP_SQL shrink $BACKUP_SQL # Now we can restart the backend. /etc/init.d/mythtv-backend start So, stop the BE, and mysql, do the myisamchk shown in /var/lib/mysql/mythconverg/, restart the mysql server, do the mysqldump of "mythconverg" shown with output going to /myth/backup/mythconverg.sql, and optionally restart the BE.

Author:	jmacmythtv [ Sat Jan 13, 2007 9:53 am ]
Post subject:
Thanks TJC - this worked with one little issue that probably explains why the script throws errors: It seems that I have a password for root to access the mythcoverg database - maybe since I have phpmyadmin installed?? So I: mysqldump -c -u root -p mythconverg > /mythtv/backup/mythconverg.sql then gave my password when asked. Is phpmyadmin installed by default or did I add this at some point and then add the password? (I do need a password since I have mythweb access on the internet - albeit through an obscure port ). Anyway, backup taken care of ... Thanks a whole bunch! However, my last post was a little premature. This morning I am back to the same symptoms of blank recordings db, inability to watch live tv. To add to my troubles, I looked back into the old compressed kernel.logs to find that I was getting the "not reading fast enough error" all the way back on Dec 18. Not too sure where to go from here...

Author:	tjc [ Sat Jan 13, 2007 10:55 am ]
Post subject:
Dunno. There were also recent threads about some buffer parameter that people were having to tweak with certain/multiple cards, however, the details are fuzzy in memory. Also, have you checked your DMA setting on the HDs? Now that you can patch together a backup, an auto upgrade might be worth trying. Remember not to leave multiple unnumbered versions of the same backup file around. I'm pretty sure that phpmyadmin isn't installed by default so this sounds like self inflicted pedal projectile damage. BTW - You can tweak the backup script to use your DB password from the command line, which will probably make life easier.

Author:	jmacmythtv [ Sat Jan 13, 2007 12:12 pm ]
Post subject:
I've read that DMA is not applicable for SATA drives but: hdparm /dev/sda1 or 2 shows HDIO_GET_MULTCOUNT failed: Inappropriate ioctl for device IO_support = 0 (default 16-bit) readonly = 0 (off) readahead = 256 (on) geometry = 30515/255/63, sectors = 2500485120, start = 9767520 and hdparm -I /dev/sda1 or 2 shows (among other things): DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 For reference, I output the myisamchk to a file and looked at it Not sure if it can cause problems, but there were several tables with large numbers of deleted blocks. For example, credits.myi had 56k rows, and 238k deleted blocks. Just for kicks I ran the -r option on all the tables which appeared to have re-indexed and eliminated the empty rows. I'll give it some time to see if this clears up the issue. I will do some searching for the buffer parameters that you are reffering to. If none of the above pans out, I will do an auto upgrade now that I can backup. Thanks again.

Author:	tjc [ Sat Jan 13, 2007 12:34 pm ]
Post subject:
jmacmythtv wrote: I've read that DMA is not applicable for SATA drives but: It's not, or rather it always does it. Then again this is the first time you've mentioned SATA drives so I had to ask.

Page 1 of 2	All times are UTC - 6 hours
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/