Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Import media crashes #65

Closed
Progi1984 opened this Issue · 70 comments

9 participants

@Progi1984

When I try the menu File > Import media, I choose my directory, that list all my pistes, and after, that tries to import it and crashs.

@Progi1984

Windows Seven 64bits

@freaktechnik

What file format?

@Progi1984

Some formats : MP3, WMA and M4A.

@freaktechnik

M4A and WMA are critical

@Progi1984

So what's next ? Some tests ?

@freaktechnik

If can find any clue what is causing the crash on the import (e.g. a specific ID3 version or a field/tag which crashs ngale), we would happy to know. But we haven't really identified yet what this is caused by afaik.

@Progi1984

Is there any log for helping in solving this bug ?

@freaktechnik

I don't think so... sadly

@Progi1984

No way for helping...

@ilikenwf
Owner

You'd have to build the debug deps...actually, @rsjtdrjgfuzkfg could use the songbird debug deps to build a debug version of ngale, so there's hope.

@rsjtdrjgfuzkfg

The main issue is that I can't reproduce it currently. I had some crashes reproduced once, but when re-trying the exact same situation (including bit-per-bit equal profile) it doesn't crash again. I plan to do a big debugging session on this, through.

For that it would probably be a good idea to work with fresh deps, but I weren't able to build all our deps on windows. That's the main issue for me currently, as we will need new deps anyway.

@Progi1984

No way for knowing what file get problems for Nightingale ?

@Appalbarry

I've just been figuring this one out. It appears that NG crashes if while scanning/importing it runs into an .m4a file. Once those files are removed the scan/import seems to work fine. (so far.)

@Appalbarry

Followup: I did search on my MUSIC directory for all .m4a files and then moved them elsewhere.

The scan/import worked fine and ran to completion. EXCEPT for one single .mp3 file that crashed it.

I'm prepared to assume that was a specific broken file, though it plays in Winamp.

My suggestion for further assessing this is to make sure all m4a files are removed and then rescan to see if any other issues come up.

@Progi1984

Finally, the question would have to be : Support for M4A & WMA in Nightingale....

Or an option : exclude some extensions from scanning

@ilikenwf
Owner

I thought that we had built-in hooks for wma and m4a's that used quicktime and windows media player - I'm sure I've seen that in the code.

Perhaps something isn't enabled? Perhaps those are being passed to gstreamer instead of the hooks?

@Progi1984

How can we see this ?

@rsjtdrjgfuzkfg

@Appalbarry try the following:
Import m4a files, until it crashes (do it one-by-one, shouldn't take long to find a crash... sadly).
After restarting on the crash, the file probably is imported (maybe without metadata - metadata reading is a possible location of the issue and I saw this behaviour already). Make sure the file is not imported and restart. Try to import the same file again. If it crashes again, we might be lucky to reproduce the issue. I hope it is a m4a under a open license, as we need the file then ;)
If it doesn't crash at the second time - well then it is like all tries I had done to reproduce this issue.... :/

@Appalbarry

OK, after an hour of trying various things, here's what seems to be happening.

After the first crashes in Windows I did a search of my MUSIC directory for *m4a, and moved all of those files to a new directory called M4A. I have been playing with importing single files, and the whole directory.

1) Sometimes some files import with no issue, but usually NG crashes.
2) Restarting and trying to import a second time does NOT crash NG.
3) Most often the imported m4a files appear as blank entries in NG, and show no metadata when that option is selected from the right click menu.
4) BUT if the same files are played, the metadata appears in the playback pane at the top.
5) Sometimes the metadata DOES show up in NG.

If I have time this weekend I'll clear all of the imported data from NG and start fresh with single files.

@ilikenwf
Owner

We should either ignore m4a's or pass them and wma's off to the built in hooks...

@freaktechnik
Owner

I saw a patch, adressing a bug in m4a import which is cuased by m4a and m4v/mp4 haveing both the MPEG-4 MIME-Type. Right now its impossible to import mp4 videos to Nightingale, they will be treated as music. Thats what I know on that topic.
and that I need m4a support or a day to cnvert my music.

EDIT: is this still windows specific?

@ilikenwf
Owner

I think a bugfix may have came with the last upstream for this, someone mind rebuilding and trying it out?

@AntoineTurmel

I also have this issue on Windows

@rsjtdrjgfuzkfg

I'm starting to work on it.

STR I will follow, please hook in if you have a working STR!

Clean Nightingale trunk (1.11 branch) debug build, clean profile, Windows 7 x64
1. Import anything I can find (audio + video) and hope for a crash with attatched debugger.

@rsjtdrjgfuzkfg

@ilikenwf yes seems to be much better now.... I added all types of not supported files and last time I did so I was able to get it to crash at least once...

If somebody has videos or audio that is available under a open license causing a crash, please upload it somewhere (small files could get uploaded via the forums, or just dropbox / mediafire it).

I uploaded a debug build to sourceforge, in case somebody wants to try it out, too. Note that debug builds aren't ment to be used without first executing "set XPCOM_DEBUG_BREAK=warn" in a terminal. Open the debug build in a terminal and you will get more verbose messages, and you can even attatch visual studio 2008 express.
Get it here: http://sourceforge.net/projects/ngale/files/testing-builds/DEBUG-Nightingale_1.11.1-2265_windows-i686.exe/download

@rsjtdrjgfuzkfg

DAMN... it is not gone on release builds. Same files crash for me on release builds. Anyway, we have a new testing build.

@rsjtdrjgfuzkfg

The issue is not reproduceable with debug builds for me, and only sometimes with release builds. Probably the issue is in the taglip dependency, I'll try to rebuild it soon. Again, if somebody has files always crashing under a open license, please upload them.

@ilikenwf
Owner

Okies... and we should also probably upgrade the taglib version we're using to current stable too...not sure what all that will entail, though.

@rsjtdrjgfuzkfg

I was able to build taglib, but it can't get updated as Songbird's taglib is patched. The main issue making an update of Nightingale's code impossible is that the Tag class from recent taglib does not support AlbumArtist, and has no custom-access api (or I just haven't found it). So we will need to patch taglib...
If anybody has an idea on where to get the patches from Songbird uses, please leave a note here.
@ilikenwf how is that issue solved on linux? Or do we use Songbird binary deps there too?

@ilikenwf
Owner

I think we've been using the songbird patched taglib as well...

We could conceivably start storing the AlbumArtist in the database, I guess...or use a different tagging library.

@rsjtdrjgfuzkfg

I personally think supporting AlbumArtist in tags is a must, as some people use their songs across applications / devices.
We might use a different tagging library, but I'd prefer to do a little patch to taglib. Note that we won't be able to add our changes to taglib probably, as from what I read on their github pull requests the devs there do not want the tag class to change because of compartibility reasons. We should contact them, through, as if I remember right there was some comment stating that Songbird's patch might be a possible starting point for a new major version number.

@ilikenwf
Owner

In the instance they won't move on it, we could certainly fork the project and call it taglib-ng or something...distros would likely pick something that was backward compatible but provided newer features like that over the old and busted version.

Either way, we should probably fork their current stable code and add the Songbird patches, and see if we can't at least start using a modern version.

@ilikenwf
Owner

Here:

https://github.com/nightingale-media-player/taglib

I can't look into patching it right now, as I'm at work, but consider it a promise :P

@ilikenwf
Owner

Here's the Songbird changes:

http://timeline.songbirdnest.com/vendor/log/trunk/taglib?action=stop_on_copy&mode=stop_on_copy&rev=11406&stop_rev=&limit=999&verbose=on

@mook and I discussed these a bit, but I'm thick headed so I'm referencing him here.

@GriffBird

Same issue with crash on mp4 here.
I've copied sbMetadataHandlerTaglib.dll and sbMetadataHandlerWMA.dll off DEBUG-Nightingale_1.11.1-2265_windows-i686.exe in the release Nightingale_1.11.0-2223_windows-i686.exe and now it won't crash but the tags are injected to the db incorrectly.
not sure if it helps isolating the problem or anything but I just thought you should know...

@rsjtdrjgfuzkfg

@GriffBird thanks for your report. I somehow have overseen your comment, so sorry for the late reply.
That might help to locate the issue, and once again this points to taglib and/or its wrappers.

We plan to change to a current taglib, but there are some issues currently (Songbird patched it, and we need to repatch our taglib repo). Hopefully that will fix the issue.

Thanks for your report!

@Manko10
Collaborator

Good news. I was able to track down and reliably reproduce this nasty bug.
The reason for the segfault crash is some broken Vorbis meta data handling so the crash only happens on OGG files but not on MP3s.

The meta data block which causes Nightingale to crash is METADATA_BLOCK_PICTURE which contains the base64 encoded album art (METADATA_BLOCK_PICTURE is the officially recommended way of embedding album art, COVERART is deprecated).

When this block exists, Nightingale crashes while importing the files (happens with big album art files of 500px and above as well as with small files of 80px).

But when it does not exist, Nightingale won't crash but import either nothing or an empty set of meta data, i.e. it adds the files to the library without any meta data assigned to them. Those are only shown in the faceplate when playing the files but neither in the library view nor in the meta data editor. Unfortunately, I couldn't figure out when it's doing what. At least it doesn't work, that's obvious.

I have uploaded a test case file with two folders containing the same (Creative Commons licensed) album, but the files in one folder contain embedded album art, the files in the other folder don't. To reproduce the issue, start over with a clean Nightingale profile (that's important because MLyrics also sometimes interferes with some strange bugs). Then choose File->Import Media and import either of the directories. The directory with the name "Crash" should cause a segfault. The folder with the name "No crash", however, should either be imported without any meta data or not at all (but it should not crash the program).

You can download the ZIP here: https://dl.dropbox.com/u/23091379/Nightingale/nightingale_w32_import_crash_test_case.zip

@Manko10
Collaborator

BTW This bug is pretty ironic

Quotation: "Failure to decode a picture block should not prevent playback of the file (failure to deal with the particularly large packet required by the comment header is a separate problem with the player implementation). "

http://wiki.xiph.org/VorbisComment#METADATA_BLOCK_PICTURE

:D

This was referenced
@AntoineTurmel

@rsjtdrjgfuzkfg
Anything new on this bug ?

@rsjtdrjgfuzkfg

@GeekShadow:
I hope to get this fixed by fixing the taglib dependency stuff. But I haven't had much luck in compiling it lately... the songbird changes are quire heavy (and somehow do not compile with my setup), while a recent taglib breaks the wrapper code.
So there is not much news on this one :/

@ilikenwf ilikenwf was assigned
@ilikenwf
Owner

Pretty sure switching to use taglib as clementine does would probably be the way to fix a ton of issues all at once, including the desire to use a vanilla taglib.

I think that if we fix this, it'll fix #110, #113, and this commit.

@rsjtdrjgfuzkfg

Please try this build and report back if the issue persists: http://sourceforge.net/projects/ngale/files/testing-builds/Nightingale_1.11.1-Taglib_windows-i686.exe/download
WARNING: this build does not save/read all metadata values, only the default ones (title, artist, genre, and some others). Other tags will only get updated in the library, thus your metadata and the data saved in library will NOT BE EQUAL WHEN USING THIS BUILD. You have been warned, I recommend using a test profile (start with -p option and create a new one if you haven't yet).

@AntoineTurmel

@rsjtdrjgfuzkfg I have tested your build and the import went fine :) (In comparison of the current 1.11 branch/trunk which crash on the same set of songs/files imported)

@rsjtdrjgfuzkfg

@GeekShadow nice to hear; what are the issues left?

@AntoineTurmel

@rsjtdrjgfuzkfg what do you mean ?

@rsjtdrjgfuzkfg

@GeekShadow you posted:

import went fine :) (In comparison of the current 1.11 branch/trunk which crash on the same set of songs/files imported)

sounds for me like it it did not work fine when not comparing to 1.11.0 but to Songbird / something else; so there are minor issues left? Or did you just want to say that it did not work on the same set of files before?

@AntoineTurmel

@rsjtdrjgfuzkfg
well to be sure I have to try with a folder with more songs (will do on my brother computer tomorrow)

@Progi1984

I am going to test on the song library which initially have had some problems.

@freaktechnik
Owner

I was able to import a few hunderd songs with this build. The import hung up (didn't crash) on a song tought, but that's probably because I used a very unfinished build of the new taglib implementation.

@rsjtdrjgfuzkfg

@freaktechnik always the same song? If so, only importing the one song works, or is it hanging then too?
Is the song cc-licensed or public domain, then you should upload it somewhere ;)
I don't think that a hang would go away when I fix the issues left in the implementation (e.g. add more tag types like albumartist, lyrics etc.)...

@freaktechnik
Owner

@rsjtdrjgfuzkfg I can't reproduce the import hanging if I reimport the song (on a new profile), where the import hung up. Looks more like an issue in the importing script then.

@Progi1984

Perfect.... I have imported 1527 files without problem.

My initial problem is solved.

@rsjtdrjgfuzkfg

@Progi1984 great :)

But tbh your problem is not yet solved, as I wouldn't recommend the use of this build in a productive environment. See the warning I posted before:

WARNING: this build does not save/read all metadata values, only the default ones (title, artist, genre, and some others). Other tags will only get updated in the library, thus your metadata and the data saved in library will NOT BE EQUAL WHEN USING THIS BUILD. You have been warned, I recommend using a test profile (start with -p option and create a new one if you haven't yet).

@Progi1984

@rsjtdrjgfuzkfg Yeap... i have seen that. I haven't any "productive" environment for Nightingale because it doesn't import my library. The next stable release will be this one.

@Manko10
Collaborator

This build works here, too. I could import my library without a crash. But when I first started it, it simply ignored all my OGG files. I had to delete the profile first.

@AntoineTurmel

@Manko10
after deleting the profile and did the import, Ogg were imported right ?

@rsjtdrjgfuzkfg
What's up on this issue ? What's left to do ? Are you able to commits changes in trunk/1.11 ?

@Manko10
Collaborator
@AntoineTurmel

@Manko10
You just sent a PGP Signature...

@Manko10
Collaborator
@rsjtdrjgfuzkfg

@GeekShadow the change is commited by ilikenwf already, in a wip branch. The issues left are advanced metadata writing, so tags other than the default ones taglib wraps out of the box. And reading of such tags.
Then a dependency update.

@rsjtdrjgfuzkfg

Just a quick update: I got the first special tag () to work, and discovered a great way to manupulate tags with the current taglib beta (1.8), which will make the migration more easy. Hope to find some time to continue soon... ;)

@rsjtdrjgfuzkfg

Again an Update:
Tag writing is there, see commit 361648b
Now we need reading, then a dependency update and many cherry-picks... in theory we can then produce release builds from it. Some clean-up would be nice, too...

@ilikenwf
Owner

Very, very nice. It will hopefully all come together between this and xul 15 :)

@rsjtdrjgfuzkfg

Removed Blocker Status.

Most likely fixed in this build: https://sourceforge.net/projects/ngale/files/testing-builds/Nightingale_1.11.1-taglib-complete_windows-i686.exe/download

Please post any issues you run into here or in the forums.

@freaktechnik

This is fixed. I can import over 2600 files at once. Formats include: m4a,mp3,wav,flac,ogg. Don't try to imprt corrupted files. It's bugged. But ngale doesn't crash in that case.

@AntoineTurmel

Reopened this bug, since it's still have to be merged at least both in sb-trunk-oldxul and nightingale-1.11 branches.

@AntoineTurmel AntoineTurmel reopened this
@rsjtdrjgfuzkfg

Merged and verified to sb-trunk-oldxul. The deps are updated too. As I think that the merge to nightingale-1.11 is a release thing and not directly related to the issue itself I close here.

@Stormdancer

I'd love to see a new official build with this soon - using version 1.11.0, build 2223 (20120305180920), which is what's linked to on the main site, this issue still exists. Only by rummaging around here did I find a version of Nightingale that didn't crash every time I tried to import my library. I think a normal user would have given up.

With the latest (Version: Nightingale 1.12, Build 0 (20130116014502) ) I was able to import all 21,844 items at once, no issues. Well done!

@rsjtdrjgfuzkfg

@Stormdancer we're working on it. If I remember it correctly, we want to release at the beginning of April...

@Stormdancer

Excellent. I feel kind of stupid, because I spent over an hour reproducing the bug and carefully documenting it, fully convinced that because I'd pulled the latest public build from the front page, that I had the fix. Derp. Thank goodness I read more carefully, before filing it!

Now... to figure out how to turn Nightingale into a PortableApps configuration.

@freaktechnik freaktechnik added the TagLib label
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.