I set MythTV up to NOT use ID3 tags (though all are tagged) and to display as folders. My MP3's are organised on an XP machine :-

F:\mp3\A\Air\Moon Safari\_Moon Safari.m3u
F:\mp3\A\Air\Moon Safari\folder.jpg
F:\mp3\A\Air\Moon Safari\All I Need.mp3
etc....

This is mapped on the mythbox to /myth/music/mp3. To see the files on the Myth box I have to scan them so it fills up the database with entries for every track (takes ages). This seems totally uncecessary though as the files are self organised. Is there a way to just traverse the directory tree in MythMusic without all the database overkill. It also means everytime I add any more music I have to rescan. Myth also ignores the m3u playlist in every album folder and the folder.jpg. Ideally it would work similarly to the way XBMC does. Is there any way this can be achieved?

If it isn't in the database the MythMusic playback stuff simply won't see it, the same goes for MythVideo, and MythTV recordings as anyone who has upgraded without a current backup can tell you. The whole MythTV system is very much DB centered.

Nightmare.

Having allowed MythTV to scan I then noticed I would get "Decoder:Mad Failed to open input. error5" when I tried to play some of the files. So I rescanned on a much smaller mp3 folder and it looks like it is going to take about 8+ hours at the rate it it going to delete all the old database entries. So I rebooted and cleared the musicmetadata table manually via Webmin (I can't wait all day), rescanned for music (2 albums) and now it plays fine. So It seems a lot of mp3 files will break MythMusic, it also seemed to list music files interspersed with folder names not in A..Z folder, then file order.

I wonder does anyone link in a different module to handle music instead of MythMusic? Something that works like XBMC would be great.

There is something else wrong with your system. If memory serves I've got about 1/4 the number of files and it takes less than a minute to scan them. A factor of four shouldn't add 8 minutes let alone 8 hours...

I didn't say how many mp3's I was originally scanning, so I'm not sure how you have 1/4 of that unknown amount

The 8 Hours was the time it would have taken for Myth to 'clear out all the old entries' from the database when I rescanned having reduced the mp3 library to 20 songs from ??,??? . The original scan of the big library took about 15 minutes as I recall. Note this was scanning from a windows network share though was not reading the id3 tags

In XBMC mp3's works perfectly, no scanning, no database, not sure why MythMusic even needs to do that when you have set it in directory mode.

I must have confused you with someone with a similar problem. They had 5-6k. Even with 10 times that I can't imagine why it would take 8 hours. I mean for the love of all things OSS, we're only talking about updating 100,000 records here. When I refresh the program guide it updates ~30,000 just in the main programs table in a couple minutes...

Well it was deleting ALL the old records apart from the 16 new ones (for the 2 albums) and in 15 minutes it had only done about 3% (checking record count in WebMin)

Sounds like the kind of SQL the scientists at work write. (I'm convinced it's because they "know" that they're really smart, so naturally what they're doing must be really hard, and so it must be normal for their queries to take days to run... After all, any dummy can come up with a query for an easy problem that only takes 5 seconds to complete. )

Check the mysql log file and file a ticket in the MythV traq system at http://svn.mythtv.org/trac/ with the problematic query or queries. This kind of stuff is easy to fix just so long as you don't assume that it's normal.

Well as I said I quit out and manually dopped/recreated the table to remove the old data = milliseconds.

can we set up a cron job to scan and import new music?


I have podcasts automatically downloading to a media-server and would like mythmusic to see them? I have a smartlist that shows only the newly imported podcasts but I have to go scan for music manually.