Can not import mp3s

[anonymous]

I just upgraded to recent SVN 13635 from an older SVN version from earlier this year. I had no problems scanning for new music prior. I have a large library of mp3s that I keep on a remote file server. After trying to scan for a handful of new tracks, they never showed up. I was unable to figure it out until I truncated my mythmusic tables and started from scratch trying to import the entire library.

It turns out that the only tracks (less than 5% of my library) successfully imported are the ones that did not contain a "~" in the final name. The naming standard I use for my tracks (and that have worked without flaw in mythmusic until recently upgrading to current SVN, is "Track# ~ Artist - SongTitle?.mp3"

I believe there has been a regression somewhere in the changes probably associated with ticket #3041 but I can't be positive.

Until this is fixed, anyone using a tilda "~" in their file names can not use mythmusic.

[stuartm]

I can't reproduce this, I changed the name of a few mp3s to "01 ~ Artist - Title.mp3" and they were found just fine.

Is there anything shown in the log during scanning? Do these mp3s have id3 tags? Do the filenames contain any non-ascii characters?

[skd5aner@…]

Unfortunantly, the logs didn't seem to be of much help on the frontend. I tried to originally import the new songs (3 of them) and after a few tries a tried it with -v all, but I can't see anything in the logs that really talk much about importing the file locations into the database other than the occasional SQL call, but nothing dealing with those files specifically.

However, I did just go into the database to look at the songs that were imported after I truncated the database. The only songs that were imported were only my .m4a tracs, and no MP3s. I know that none of my .m4a tracks have a "~" in the file name. What I'll do next is change one of my MP3's to not have a tilda and one of my .m4as to have a tilda and see what happens.

[skd5aner@…]

Well, I just did two tests:

1) Add a tilda (~) in the filename of an .m4a file.

• This file was added succesfully during a scan.

2) Remove the tilda from an .mp3 file

• This file was still not added during the scan.

So, at very least, this ticket needs an updated description because it doesn't have to do with the tilda. However, it's not importing MP3's that it had always succesfully been able to import before through the "Scan for new music" option. And to answer your previous questions:

• All of my MP3s have both v1 and v2 ID3 tags
• 99% of them probably don't have any form of non-ascii character in either the file name or the ID3 tag, but I'm sure there are probably a few dozen that might have an umlat or something else.

Please let me know if there is any more information that you'd like me to provide.

[stuartm]

Although it shouldn't be possible to build mythmusic without them, can you check that you have the build dependencies installed? Taglib (not libid3tag) and LibMad? in particular. Re-running configure should show any missing libraries. It's a stretch but I can't think of a better explanation just now.

[skd5aner@…]

On Ubuntu Feisty: libtag1-dev is already the newest version. libtag1c2a is already the newest version. libmad0-dev is already the newest version. libmad0 is already the newest version.

None of these packages are installed on my master backend, just the frontend. Everything compiled just fine.

One other piece of information to expand upon. My entire music library is stored remotely on my window's box and is mounted via cifs. However, this is how I've always had it for the last several years as well with now issues (with the same library).

[stuartm]

(In [13670]) Refs #3607

Make the read metadata checks more robust. If reading from tags fails completely, try from the filename and if that fails log the error.

[stuartm]

I'm going to say that cifs is probably the cause of the problem.

I had no problem with a sample file sent by the reporter, it was imported, played fine and even the albumart was read from the ID3 tag.

The following post on the taglib-devel mailing list might be relevant: ​http://lists.kde.org/?l=taglib-devel&m=113280000707324&w=2

[skd5aner@…]

I had a long reply typed up and thought "hey, I'll give it a shot and try changing the mount options for CIFS" and lo and behold - it worked. My entire library imported.

I really only changed one thing. I added ",ro," to the options in /etc/fstab for that line. It was read-only be to begin with, and nothing else I have is affected negatively except this specific instance. I have no idea what the consequence would be if I didn't want this to be read-only. Luckily, in my case I do.

I really don't get it, but that did fix it. However, I wouldn't say that this is a bug in CIFS or SMBFS, as this worked fine before the change to taglib. I'm assuming this is some sort of bug upstream in taglib, but not sure much can be done about it at the myth level? Not sure why the switch to taglib vs libid3tag, but might be something to consider as this problem never came up with the old libraries with the same mounting system. Although I'm sure there was good reason behind the switch.

Anyway, thanks for helping troubleshoot this Stuart and also for the overall improvements you've been trying to make to mythmusic recently.

[stuartm]

I'll keep this in mind and see if there isn't something that can be done to have taglib behave itself, but I'll close the ticket for now.

The switch to taglib was done for a number of reasons. The main one is speed, taglib is several times faster than libid3tag, meaning that scanning times are much, much reduced. Secondly taglib supports a number of tag formats, meaning it can eventually replace the current ogg and flac tagging code making things easier to maintain. Thirdly it uses a high level API which is much simpler to use than libid3tag and supports far more things natively. If another reason was needed, it is also actively maintained whereas development of libid3tag was dead.