maemo.org Bugzilla – Bug 3970
Media player doesn't detect media files / cannot restart metalayer-crawler
Last modified: 2010-08-18 20:56:19 UTC
You need to log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: 5.2008.43-7 STEPS TO REPRODUCE THE PROBLEM: I don't know how to reproduce the root problem. Now, restarting the device or manually launching the metalayer-crawler process fails. EXPECTED OUTCOME: metalayer-crawler running and updating Media Player library ACTUAL OUTCOME: Cannot start metalayer-crawler REPRODUCIBILITY: always EXTRA SOFTWARE INSTALLED: OTHER COMMENTS: Media Player began to fail a few days ago. Doesn't update the library (not detect new files and doesn't remove those who no longer exist). I found that the metalayer-crawler is not running. I tried to manually run it in different ways: without arguments and with -F, as root or as user. In any case it worked, using -F I get Segmentation fault. I deleted the file .meta_storage and still cannot make start the metalayer-crawler and with -F Segmentation fault persists. I removed the miniSD card and format the internal memory assuming that the crawler may have trouble with some files, but nothing changed. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.36 Safari/525.19
I'm afraid I can't add anything useful except 'me too'. I only noticed it yesterday when Media Player suddenly had an empty audio/vido list. I found out that metalayer-crawler wasn't running (ps), so I tried starting it; only when I used the option -F I found it gave a segmentation fault. 5.2008.43-7, too.
Could you attach a core dump of the crawler process (after installing sp-endurance)? I'd like to verify that it's the same thing as internal bug 92017.
(In reply to comment #2) > Could you attach a core dump of the crawler process (after installing sp-endurance)? Sorry, I meant sp-rich-core. You can install it according to instructions here: http://maemo.org/development/tools/ After that, core-dumping is enabled just by creating "core-dumps" directory to a memory card having enough free space. To disable core-dumping, just remove the directory.
Created an attachment (id=1078) [details] rich coredump I have no idea what I'm doing here. It might be that this attachment is what you asked for. If not - pls. give me detailed step-by-step instructions. :)
(In reply to comment #4) > Created an attachment (id=1078) [details] [details] > rich coredump > > I have no idea what I'm doing here. It might be that this attachment is what > you asked for. If not - pls. give me detailed step-by-step instructions. :) Thanks, this is the correct thing. However, for some reason I don't get proper backtrace, I can only see that the crash happens within glib. Did you update to 5.2008.43-7 with SSU instead of re-flashing the device?
(In reply to comment #5) > (In reply to comment #4) > Did you update to 5.2008.43-7 with SSU instead of > re-flashing the device? Sure. I'm so glad I don't have to re-flash anymore.
(In reply to comment #6) > > Did you update to 5.2008.43-7 with SSU instead of > > re-flashing the device? > > Sure. I'm so glad I don't have to re-flash anymore. So SSU makes the Crash reporter less useful because backtraces don't work automatically[1]. Damian, did you update to w43 by flashing or SSU and if it was by flashing, could you provide also a core-dump? Thanks! [1] Bins&libs on the flashed image are prelinked (to improve startup speed and memory usage), ones in SSU packages aren't (because pre-linking isn't done per package, but per image). As a result function addresses differ and Gdb is confused). Dang. :-/
(In reply to comment #7) > Damian, did you update to w43 by flashing or SSU and if it was by flashing, > could you provide also a core-dump? Thanks! I did the update using SSU too.
(In reply to comment #8) > (In reply to comment #7) > > Damian, did you update to w43 by flashing or SSU and if it was by flashing, > > could you provide also a core-dump? Thanks! > > I did the update using SSU too. > Is there any way to create an image of my NIT? If so, I could create and attach to the bug
> Is there any way to create an image of my NIT? If so, I could create and attach to the bug No need. It's possible to get backtraces also for SSU updates done on top of the release images, as long as one knows which updates were done (which packages are from the original image, what version that image had, which packages are from SSU and which SSU version), it just needs much more effort. For now I'll just assume this is NB#92017 as that came in w43 release (maintainer had applied a bad patch to crawler and it was found out & reverted only several weeks later) and you didn't have the issue before. NB#92017 is fixed internally, but I don't know when the updated crawler will be released.
(In reply to comment #10) > For now I'll just assume this is NB#92017 as that came in w43 release > (maintainer had applied a bad patch to crawler and it was found out & reverted > only several weeks later) and you didn't have the issue before. NB#92017 is > fixed internally, but I don't know when the updated crawler will be released. ... and I assume there's no known workaround? Would re-flashing help? I'm asking because there's at least one person who is not affected - and he flashed to 43-7 instead of doing an SSU. (qwerty12 in the itt-thread linked to this bug.)
FYI, int-92017 is fixed in internal Diablo build version x.2008.47 (Note that 2008 is the year and the number after is the week.) Any public update released with or after this build version will include the fix. Would be great to get feedback here once the next update is available for public.
(In reply to comment #11) > ... and I assume there's no known workaround? You could force install of the previous versions of libmetalayer/-crawler (with "apt-get install <package name>=<version>"), but for that you'll need to remove the SSU packages version lock package. The previous crawler version crashes with VMA files that have NULL attributes, but if you don't have such files (you didn't have crashes earlier), everything should be fine. You can see the available versions with "apt-cache policy <package name>". To do further SSU updates, you'll need to re-install the lock package (as SSU updates are based on upgrading the lock package). > Would re-flashing help? I'm asking because there's at least one person > who is not affected - and he flashed to 43-7 instead of doing an SSU. I assume this is a co-incidence and just depends from what kind of content (dirs & files) he has in MyDocs and memory cards.
Created an attachment (id=1091) [details] Fixed version of metalayer-crawler for testing Attached is a package of metalayer-crawler that should have this bug fixed, if this bug is the same one as the internal one. To install it you need to remove the osso-software-version-* SSU update lock meta package because it depends on the w43 version of crawler i.e. you need to do the install as root from command line and force the installation of the newer version (I don't think you can do that from the Application manager). To enable SSU again, you need to re-install the lock meta package that gets removed (along with the version of crawler it pulls in).
(In reply to comment #14) > Attached is a package of metalayer-crawler that should have this bug fixed, if > this bug is the same one as the internal one. Good news: It works again, so probably this *is* the same bug as the internal one. Thank you for making this available. > To install it you need to remove the osso-software-version-* SSU update lock > meta package because it depends on the w43 version of crawler technobabble Bad news: I guess I really, really spoiled this part. I should have asked before but was so eager to test it... :( I wasn't sure which "osso-software-version-*" (I have an N800), don't know may way through apt-whatever... and when I just wanted to know what would happen on a dpkg -i with your package it simply installed and worked. Outch. So this will probably break something sooner or later on my tabet, will it? If somebody who follows this could maybe give a short notice on what exactly I should have done and how to clean up the mess I caused I'd be delighted. ;)
(In reply to comment #15) > Good news: > It works again, so probably this *is* the same bug as the internal one. > Thank you for making this available. Thanks for testing! :-) > > To install it you need to remove the osso-software-version-* SSU update lock > > meta package because it depends on the w43 version of crawler technobabble > > Bad news: > I wasn't sure which "osso-software-version-*" (I have an N800), don't know may > way through apt-whatever... and when I just wanted to know what would happen > on a dpkg -i with your package it simply installed and worked. Outch. I guess it has gotten uninstalled earlier by something else you've installed. This isn't dangerous, it just means that you cannot do SSU update before you re-install the "lock" package. See: http://wiki.maemo.org/Seamless_Software_Update
Can the fixed package be upload to the repository. At the moment it blocks the "OS2008 Feature upgrade" because this depends on metalayer-crawler = 0_1.3.19-2 Or can just the "OS2008 Feature upgrade" dependencies be fixed, so that it will also work with metalayer-crawler 0_1.3.19-3 thanks
(In reply to comment #17) > Can the fixed package be upload to the repository. At the moment it blocks the > "OS2008 Feature upgrade" because this depends on metalayer-crawler = 0_1.3.19-2 > > Or can just the "OS2008 Feature upgrade" dependencies be fixed, so that it will > also work with metalayer-crawler 0_1.3.19-3 > > thanks The problem is that it's "core" and considered an integral part of the SSU. What WOULD be nice is if there was an SSU pushed out to fix this problem sooner rather than later (of course, with Fremantle in the works... sigh). Personally, I couldn't wait any longer so I installed the fix here which worked as expected. The problem I have right now is that the lock file and the current version of metalayer-crawler this SSU expects is NOT linked to from this bug report. Without these, it's going to be very hard to un-break the SSU and get the tablet in a state to accept the next one when it is released. Eero, can you please do that? Thank you!
(In reply to comment #18) > The problem I have right now is that the lock file and the current > version of metalayer-crawler this SSU expects is NOT linked to from this bug > report. I didn't quite understand above... > Without these, it's going to be very hard to un-break the SSU and get > the tablet in a state to accept the next one when it is released. I think you should be able just to install the "old" SSU lock to get any new SSU (if/when such will be available). It will of course downgrade crawler and any other system package you've upgraded, but I hope you can be without music when the device is updated. > Eero, can you please do that? Thank you! I don't have any control over SSU.
Yes. Exactly. I want to have the old metalayer-crawler on hand so when I need to I can apply the 5.2008.43-7 package and fix my tablet's SSU state. Without it, anyone who dpkg'd this version won't be able to get back on track with the SSUs, correct? When I look at the 5.2008.43-7 SSU in Application Manager, it says it *can't* update to because metalayer-crawler != 1.3.19-2 -- "Broken and cannot update." So yeah, all I'm asking for is to make metalayer-crawler v1.3.19-2 available here so we can install it later when we need to. Unless there is a better way of doing it (apt-get perhaps)? Just please add the binary or explicit instructions on how to do it, thanks.
(In reply to comment #20) > Yes. Exactly. I want to have the old metalayer-crawler on hand so when I need > to I can apply the 5.2008.43-7 package and fix my tablet's SSU state. mara said on itt there won't be another SSU, anyway. why bother?
(In reply to comment #21) > mara said on itt there won't be another SSU, anyway. why bother? Oh? What's the URL of that comment?
Suddenly, this morning started to operate without any revision. Even with v5.2008.43-7 & SSU. I do not understand.
(In reply to comment #22) > (In reply to comment #21) > > mara said on itt there won't be another SSU, anyway. why bother? > > Oh? What's the URL of that comment? Actually, two posts. The second gives more details http://www.internettablettalk.com/forums/showpost.php?p=269692&postcount=6 and http://www.internettablettalk.com/forums/showpost.php?p=270130&postcount=13 You probably want to look at the whole thread to see the context.
sorry, I can't understand this. the using of dpkg in maemo is a bit low. the sence of such package system like dpkg is, that it handle dependencies for you. If I try now "apt-get install gpxview" I get this error: Reading package lists... Done Building dependency tree Reading state information... Done You might want to run ‘apt-get -f install’ to correct these: The following packages have unmet dependencies. osso-software-version-rx44: Depends: metalayer-crawler0 (= 1.3.19-2) but 1.3.19-3 is to be installed E: Unmet dependencies. Try ‘apt-get -f install’ with no packages (or specify a solution). This can't be correct. Why metalayer-crawler0 1.3.19-3 can't be uploaded? Why can't the dependencies of osso-software-version-rx44 not changed to metalayer-crawler0 (>= 1.3.19-2)? Who is responsible for osso-software-version-rx44? Kind regards, Keywan
(In reply to comment #25) > Why metalayer-crawler0 1.3.19-3 can't be uploaded? I think because Nokia has a heavy-weight testing and release process and in the past they've been collecting several fixes before making a big SSU update available for public. (In general: I know that we'd all like to see smaller && more frequent updates, but I guess that Nokia has to change some internal testing organization structure to get there.)
*** Bug 4574 has been marked as a duplicate of this bug. ***
someone make a step-by-step instruction, pls.
Can we please get some step-by-step instructions on how to fix this manually since this is an important part of the tablet's main functionality?
Okay, I figured this out myself. Here's how I did it. 1) Download the fixed version of metalayer-crawler attached to this bug. Put it anywhere on your tablet that's easily accessable. 2) Open an X terminal. 3) Gain root (however you choose to do that). 4) Run "apt-get remove osso-software-version-rx44" (if you have N810, I think it's rx34 for the N800... it's listed in this bug somewhere already). When asked, hit Y to confirm. 5) Run "dpkg -i /path/to/(name of fixed metalayer-crawler deb here)" It should then start working and scanning immediately. You can then close the terminal.
I did the dpkg -i, and installation was successful. I have a N800, and osso-software-version-rx34 WAS installed, but I didn't touch it!... Wasn't the installation supposed to fail? It seems the crawler started working back again. Problem is now it's not finding my ogg songs (which is most of my collection). ogg-support is installed. Is this expected?...
ogg-support was a 3rd party patch. Might be that this broke.
Unfortunately, something seems to have gone *very* wrong here since installing the fixed version of metalayer-crawler. Everything worked fine for a while... I had about 1200 mp3s on a 16GB external microsd card in a minisd adapter. Everything worked great until I decided to play one song from my memory card through the file manager. Doing so replaces the entire Now Playing playlist with a new playlist holding that single song, which is fine and expected behavior... but then suddenly, when I tried to play a song in my library, it wouldn't happen. Errors left and right such as "unable to complete operation" and "unable to play". When I would get the "unable to complete operation" error and I would back out of my Songs portion of the library, I would see that suddenly I had zero artists and zero albums, but 1200 songs and 1200 genres, which clearly wasn't correct. I've removed the .meta_storage file, removed and reinserted my memory card, allowed metalayer-crawler to run and it appears to do its job... but attempting to actually play any of the music results in the "Unable to play" error coming up. Even attempting to play a single song from the file manager as I originally did doesn't work. I can see that the proper paths are found in .meta_storage. So I'm now stuck with a completely non-functional media player. I'm going to attempt to play some songs using a program that will play through osso media and see if it works... and I guess I might just reflash and reformat my memory card as well.
Hi, I fear I am affected by this bug.... how comes that status is set Resolved ? while it's not installable the regular way ? There should be a way to revert to working configuration, without installing, reflashing anything , am I wrong ? Regards Ps: set OS: to all , since I dont use windows :) -- http://rzr.online.fr/q/player
(In reply to comment #34) > how comes that status is set Resolved ? while it's not installable the regular > way ? It was FIXED internally for Maemo4 but Nokia has never made the fix available for public. (metalayer-crawler does not exist in Maemo5.)
(In reply to comment #34) > how comes that status is set Resolved ? while it's not installable the regular > way ? Comment 30 explains how to installed the attached package for the fixed version of the daemon. Only difference in that from the version in the previous public release is reverting one bad patch. No idea about the issue in comment 33.
I confirm this package upgrade workaround seems to work for me (including ogg files, not .ogv or .oga) But can't this deb moved into a APT repo ? or better provide srcs :-) Are there known workaround to make current one (from the firmware) working when this case occurs ? I consider this bug is still not fixed for public ... but who cares ? :-) -- http://rzr.online.fr/q/player