[mythtv-users] Takes long time to enter "Watch Recordings" menu

Wed Feb 28 16:54:30 UTC 2007

Phil Smith wrote:
> On Feb 27, 2007, at 11:33 AM, myth at dermanouelian wrote:
>  > On Feb 27, 2007, at 9:22 AM, erland wrote:
>  >
>  >>
>  >> Suddenly it has started to take a lot of time to enter the "Watch  >>
> Recordings"
>  >> menu in MythTV, earlier it has been a bit slow and taken maybe 5  >>
> seconds but  >> now it has started to take about 30 seconds instead.
>  >>
>  >> The problem is reproducable both on the frontend running on the  >> same
> machine  >> as the backend but also on a separate frontend running on a
> laptop.
>  >> The CPU
>  >> usage during the 30 seconds seems to be less than 20% on both the  >>
> frontend+backend machine and the separate frontend on the laptop,  >> so I
> don't  >> think it is a CPU problem. Sometimes on the laptop I have even  >>
> gotten a  >> message saying that the connection with the backend has been
> lost.
>  >>
>  >> Most of the other menus works as fast as before, and it is also  >> fast
> to step  >> around inside the "Watch Recordings" menu while you have
> successfully  >> entered it.
>  >>
>  >> The only difference I can see is that the number of saved  >> recordings
> is a  >> bit more, there are about 370 saved recordings at the moment.
>  >>
>  >> Has someone else seen the same problem and knows if there is a  >>
> workaround ?
>
>  >Try running optimize_mythdb.pl
>
> I already tried running optimize_mythdb.pl, but it didn't make any
> difference, the problem still remains.
>
> Neither the mythbackend, mythfrontend nor the mysql process seems to use any
> CPU at the time. The only CPU usage regaring myth was some commercial
> flagging job that were executed. But the problem is also reproducable when
> no jobs are running and then the CPU is pretty much 100% idle.
>
> ------------------------
>
> It could be missing recordings, or recordings a slave backend that is not
> there.  When you go into 'watch recordings' myth tries to generate the
> previews, which it if cannot find can take a while to time out.
>
> Try turning off the previews, or run with a higher level of logs to see what
> it it trying to do.
>
>   

I tried to turn off the previews but it didn't help, there is no slave 
backend there so that is not the problem. The last recordings are stored 
on the local harddrive but older recordings are stored on a drive on a 
remote machine and that drive is mounted with samba. For the old 
recordings there is a link from the local drive to the remote drive 
mounted with samba.

The latest recordings are stored on a local harddrive, older recordings 
is moved every night to another machine using mv and the mythrename.pl 
script. The local hard disk is not spin down, the drives on the remote 
server might be since these are USB drives.

I just noted a problem that might be related, the following commands 
takes a lot of time (like 25 seconds):
ls -l /mnt/video/*.mpg

The strange thing is that this is really fast (a lot less than a second):
ls -l /mnt/video/*.mpg|wc
ls -l /mnt/video/*.mpg >test.txt

I really doesn't understand whats going on here and if this has anything 
to do with the problems.

ls -l with a specific file or link as parameter seems to be fast, for 
example "ls -l /mnt/video/xxx.mpg"

ls -l /mnt/video1/*.mpg (which is the mounted remote USB disk) is really 
fast.
ls -l /mnt/video2/*.mpg (which is the mounted remote USB disk) is really 
fast.

Here is the log from the frontend when running with -v all when entering 
the watch recordings menu
=========================
2007-02-28 17:43:30.801 Connecting to backend server: 172.16.0.114:6543 
(try 1 of 5)
2007-02-28 17:43:30.802 MythSocket(8c9a2a8:10): new socket
2007-02-28 17:43:30.802 MythSocket(8c9a2a8:10): attempting connect() to 
(172.16.0.114:6543)
2007-02-28 17:43:30.803 MythSocket(8c9a2a8:10): state change Idle -> 
Connected
2007-02-28 17:43:30.803 write -> 10 21      MYTH_PROTO_VERSION 30
2007-02-28 17:43:30.805 read  <- 10 13      ACCEPT[]:[]30
2007-02-28 17:43:30.806 Using protocol version 30
2007-02-28 17:43:30.806 write -> 10 36      ANN Monitor 
inspiron8600lin_erland 0
2007-02-28 17:43:30.815 read  <- 10 2       OK
2007-02-28 17:43:30.815 MythSocket(888b748:9): attempting connect() to 
(172.16.0.114:6543)
2007-02-28 17:43:30.817 MythSocket(888b748:9): state change Idle -> 
Connected
2007-02-28 17:43:30.817 write ->  9 36      ANN Monitor 
inspiron8600lin_erland 1
2007-02-28 17:43:30.825 read  <-  9 2       OK
2007-02-28 17:43:30.825 MythSocket(888b748:9): UpRef: 1
2007-02-28 17:43:30.825 write -> 10 21      QUERY_RECORDINGS Play
2007-02-28 17:43:30.826 MythSocket: readyread thread start
2007-02-28 17:43:53.294 read  <- 10 255276  373[]:[]Stepford Wives[]:[][]:
=============================
The last line is cut, it lists all recordings but was a bit long to 
include in the mail.
The problem is that there is 23 seconds between the two last lines in 
the log.

I'll try to turn up the log level on the backend also and see if I can 
provide a log from the backend, with the default logging level the 
backend log doesn't show anything interesting.

Also some history about what have happend lately in the setup:
1. I recently installed a new USB drive on the remote server where old 
recordings are stored, its mounted as /mnt/video2 on the MythTV backend 
machine using samba.
2. The result of adding the extra USB drive is that the number of 
recordings increased a bit compared to before since there is now a bit 
more space.

Regards
Erland