View unanswered posts    View active topics

All times are UTC - 6 hours





Post new topic Reply to topic  [ 23 posts ] 
Go to page 1, 2  Next

Print view Previous topic   Next topic  
Author Message
Search for:
PostPosted: Wed Jan 10, 2007 8:43 pm 
Offline
Joined: Sun Mar 19, 2006 10:42 am
Posts: 89
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]


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 10, 2007 9:45 pm 
Offline
Joined: Sat Feb 11, 2006 10:08 pm
Posts: 25
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 10, 2007 10:10 pm 
Offline
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location: Arlington, MA
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...


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jan 11, 2007 7:16 am 
Offline
Joined: Sun Mar 19, 2006 10:42 am
Posts: 89
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!


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jan 11, 2007 7:23 pm 
Offline
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location: Arlington, MA
Have you monkeyed with the DB at all? Changed passwords, set up access for a remote front end, ...?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jan 11, 2007 8:04 pm 
Offline
Joined: Sun Mar 19, 2006 10:42 am
Posts: 89
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?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jan 11, 2007 8:08 pm 
Offline
Joined: Sun Mar 19, 2006 10:42 am
Posts: 89
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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jan 11, 2007 8:45 pm 
Offline
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location: Arlington, MA
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. ;-)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jan 11, 2007 9:15 pm 
Offline
Joined: Sun Mar 19, 2006 10:42 am
Posts: 89
oops ... any chance that I get can things in sync again ... or is the system a write-off?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 12, 2007 6:42 pm 
Offline
Joined: Sun Mar 19, 2006 10:42 am
Posts: 89
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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 12, 2007 7:53 pm 
Offline
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location: Arlington, MA
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jan 13, 2007 9:53 am 
Offline
Joined: Sun Mar 19, 2006 10:42 am
Posts: 89
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...


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jan 13, 2007 10:55 am 
Offline
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location: Arlington, MA
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jan 13, 2007 12:12 pm 
Offline
Joined: Sun Mar 19, 2006 10:42 am
Posts: 89
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jan 13, 2007 12:34 pm 
Offline
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location: Arlington, MA
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.


Top
 Profile  
 

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 23 posts ] 
Go to page 1, 2  Next



All times are UTC - 6 hours




Who is online

Users browsing this forum: No registered users and 18 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group

Theme Created By ceyhansuyu