Bug 3970 - (int-92017) Media player doesn't detect media files / cannot restart metalayer-crawler
(int-92017)
: Media player doesn't detect media files / cannot restart metalayer-crawler
Status: RESOLVED FIXED
Product: Data
metalayer-crawler
: 4.1.3 (5.2008.43-7)
: N810 Windows
: High major with 2 votes (vote)
: 4.1+
Assigned To: unassigned
: metalayer-crawler
: http://www.internettablettalk.com/for...
: crash
:
:
  Show dependency tree
 
Reported: 2008-12-29 14:14 UTC by Damián D'Onia
Modified: 2010-08-18 20:56 UTC (History)
12 users (show)

See Also:


Attachments
rich coredump (276.70 KB, application/x-lzop)
2008-12-29 16:39 UTC, Oskar
Details
Fixed version of metalayer-crawler for testing (13.17 KB, application/x-debian-package)
2009-01-07 17:16 UTC, Eero Tamminen
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Damián D'Onia (reporter) 2008-12-29 14:14:41 UTC
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
Comment 1 Oskar 2008-12-29 15:39:15 UTC
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.
Comment 2 Eero Tamminen nokia 2008-12-29 15:57:57 UTC
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.
Comment 3 Eero Tamminen nokia 2008-12-29 16:27:13 UTC
(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.
Comment 4 Oskar 2008-12-29 16:39:22 UTC
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. :)
Comment 5 Eero Tamminen nokia 2008-12-29 17:20:46 UTC
(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?
Comment 6 Oskar 2008-12-29 17:26:12 UTC
(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.
Comment 7 Eero Tamminen nokia 2008-12-29 18:09:16 UTC
(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. :-/
Comment 8 Damián D'Onia (reporter) 2008-12-29 21:13:16 UTC
(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.
Comment 9 Damián D'Onia (reporter) 2008-12-29 23:16:29 UTC
(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
Comment 10 Eero Tamminen nokia 2008-12-30 11:21:40 UTC
> 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.
Comment 11 Oskar 2008-12-30 12:04:46 UTC
(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.)
Comment 12 Andre Klapper maemo.org 2008-12-30 12:50:03 UTC
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.
Comment 13 Eero Tamminen nokia 2008-12-30 12:53:57 UTC
(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.
Comment 14 Eero Tamminen nokia 2009-01-07 17:16:14 UTC
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).
Comment 15 Oskar 2009-01-09 00:57:06 UTC
(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. ;)
Comment 16 Eero Tamminen nokia 2009-01-09 12:11:49 UTC
(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
Comment 17 Keywan Najafi Tonekaboni 2009-02-18 13:39:43 UTC
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
Comment 18 Noah Mittman 2009-03-19 00:19:45 UTC
(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!
Comment 19 Eero Tamminen nokia 2009-03-19 08:46:31 UTC
(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.
Comment 20 Noah Mittman 2009-03-23 18:34:11 UTC
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.
Comment 21 Oskar 2009-03-23 18:48:14 UTC
(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?
Comment 22 Andre Klapper maemo.org 2009-03-23 18:56:24 UTC
(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?
Comment 23 Damián D'Onia (reporter) 2009-03-23 19:05:28 UTC
Suddenly, this morning started to operate without any revision. Even with
v5.2008.43-7 & SSU. I do not understand.
Comment 24 Oskar 2009-03-24 09:23:22 UTC
(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.
Comment 25 Keywan Najafi Tonekaboni 2009-03-29 15:13:13 UTC
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
Comment 26 Andre Klapper maemo.org 2009-03-30 14:36:19 UTC
(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.)
Comment 27 Thiago 2009-05-22 18:15:22 UTC
*** Bug 4574 has been marked as a duplicate of this bug. ***
Comment 28 Thiago 2009-05-22 18:31:05 UTC
someone make a step-by-step instruction, pls.
Comment 29 Jason Carter 2009-08-10 17:46:40 UTC
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?
Comment 30 Jason Carter 2009-08-10 18:12:43 UTC
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.
Comment 31 Nicolau Leal Werneck 2009-08-10 19:13:23 UTC
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?...
Comment 32 Andre Klapper maemo.org 2009-08-10 19:18:02 UTC
ogg-support was a 3rd party patch. Might be that this broke.
Comment 33 Jason Carter 2009-08-13 15:53:55 UTC
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.
Comment 34 rzr 2010-08-17 21:50:58 UTC
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
Comment 35 Andre Klapper maemo.org 2010-08-17 21:59:10 UTC
(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.)
Comment 36 Eero Tamminen nokia 2010-08-18 14:22:28 UTC
(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.
Comment 37 rzr 2010-08-18 20:56:19 UTC
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