I use the /myth/pretty directory over Samba on an Apple TV running XBMC. But since my upgrade last weekend (to R7.4) - /myth/pretty doesn't contain all my recordings. But it gets way weirder than that...

To start the description of the problem - I use Storage Groups with my recordings spread across several drives, some local (SATA and USB) and some mounted across NFS (but that doesn't appear to really have anything to do with the problem). After the upgrade - I noticed that /myth/pretty only had a small subset of my recordings (70 vs. more than 2000). This appears to only be the recordings from my first Storage Group. This system can date itself back to 2004 - way before Storage Groups were part of MythTV.

So the first thing I did was run mythlink.pl manually and it worked fine and pulled all the recordings in properly. I had a look at the entry in /etc/cron.hourly and then ran that script directly - once again it was good, all recordings were there.

So I figured the issue was related to the the cron execution of the script and I modified it a bit. My changes would "touch" a file and log the verbose output of the mythlink.pl. The problem was - the changes weren't *always* present! Sometimes my file was touched and other times, the recording links were missing and my test file hadn't been touched!

So - I then noticed several things:

1) There were two different copies of mythlink.pl on the system - one at /usr/bin and one at /usr/share/mythtv/contrib/user_jobs. This doesn't appear to be a big deal - because the one at /usr/bin is the one that runs.

2) There appears to be something calling a "pretty" script at xx:41 and xx:49 every hour. This is the one that only appears to be creating links for my first Storage Group. My initial fix was to run the "proper" mythlink.pl at xx:42 and xx:50. Obviously not a great solution.

I've completely pulled all cron jobs related to mythlink.pl out of the system - but something is still running at xx:41 and xx:49!! It is not coming from cron.d, cron.hourly or the crontab's of either root or mythtv. I've completely disabled (actually mv'd the two scripts mentioned above). I have an old pretty cron job in /etc.old that I've also chmod'd to stop any chance of execution.

It's very odd - and it bugs me that I can't find it. I figure there must be a cron job being triggered someplace - or something within MythTV?

It was working fine until last Saturday (for years - since I started using the pretty functionality) on R7.1.

Any ideas? My cron at xx:42 and xx:50 seem like such kludges... Anybody else see this with R7.4?!?

I'm not sure if it's a bug in R7.4 or something that has crept into my system...

I have seen the same thing on R7.4 but haven't looked into it further.

Same thing here. Similar usage as well. I watch TV with VLC from my windows box via the pretty folder. If I manually run the /etc/cron.hourly/pretty script, all of my shows are listed. At some point during the hour, the directory gets changed to only a list a small subset of my shows on my first storage group. I haven't been able to figure out how or why another process is running, that incorrectly populates the directory. How did you figure out when the rogue pretty script was running?

_________________
BE: R8.4, HVR2250, MCE media center remote, GigaByte GA-EP43-UD3L, 2gb ram

FE: Linhes 8.4, Mythbuntu, Linux Mint DE

I recall that I disabled all the cron calls to the pretty script and manually watched for when the /myth/pretty directory was updated. Some other process is triggering the erroneous call.

I ran out of time trying to fix/track down the root cause of this issue - and just setup cron to run the "good" script every ten minutes...

I believe the script is being run by mythbackend. If I recall properly, a while ago I was troubleshooting some other problem and turned on verbose messages from mythbackend. I noticed that it would periodically run some routines that I wasn't aware of, something about housekeeping.

You could try running mythbackend on the console or modify the startup command to increase the verbosity.

For console output, get to a console (virtual terminal, xterm, or ssh) as mythtv. Stop the mythbackend service:

$ sudo sv stop mythbackend

Start mythbackend on the console:

$ /usr/bin/mythbackend -v --loglevel debug

This will spew a lot of messages to the console. You might want to send the ouput to a file for later analysis. Use the --logpath option.

To modify the default logging from the service you need to modify the "run" script.

$ sudo sv stop mythbackend
$ cd /etc/sv/mythbackend
$ sudo vi run

Then near the end of the file change the command line option to mythbackend to increase the loglevel. When you are done, restart the mythbackend service:

$ sudo sv start mythbackend

Look at the log /var/log/{todays_date}/mythtv_mythbackend.{pid_of_running_mythbackend}.log

A third option is to replace/modify the "bad" script. But it doesn't seem clear that you know which one it is. Have you actually found the "bad" script?

Gus

Thanks for the info.

I never found the bad script - I moved the two scripts I found (locations in my original post) so that they couldn't run, but the "bad" update still ran regularly.

I now have a local copy of mythlink.pl located under /root that I encapsulated in a script and run it every five minutes (not ten like I mentioned in my last post).

It *almost* appeared like the update code was running from within some other script - but I stopped trying to find the culprit...