Bug 311847

Summary: no track number in Nepomuk Collection
Product: [Applications] amarok Reporter: Tomasz Meresiński <tomasz>
Component: Collections/NepomukAssignee: Amarok Developers <amarok-bugs-dist>
Status: RESOLVED FIXED    
Severity: normal CC: karthik.periagaram, maddiemadan, me
Priority: NOR    
Version: 2.6.90 (2.7 beta)   
Target Milestone: 2.7   
Platform: Arch Linux   
OS: Linux   
Latest Commit: http://commits.kde.org/amarok/1081fc2eb3cf0f5ea858ea55257c2033615a031f Version Fixed In: 2.7.1
Sentry Crash Report:

Description Tomasz Meresiński 2012-12-17 19:39:29 UTC 
All songs in my Nepomuk Collection don't have track number tag which makes that type of collection useless for me. It can also be problem with my (default) Nepomuk configuration.
I compiled Amarok Beta with AUR.

Reproducible: Always

Steps to Reproduce:
1. Start Nepomuk Collection
2. Open any album in collection
Actual Results:  
No song has track number tag

Expected Results:  
Track number tags should exist in Nepomuk Collection
Comment 1 Mayank Madan 2012-12-19 08:27:36 UTC 
I can reproduce this in v2.6.90-26-gbcdd84c
Comment 2 Mayank Madan 2012-12-19 19:07:53 UTC 
The tracks in nepomuk collection doesnt really have any track numbers.
Comment 3 Myriam Schweingruber 2012-12-21 14:51:32 UTC 
Setting status correctly.
Comment 4 Phalgun Guduthur 2012-12-23 16:23:30 UTC 
This is 'cos of Strigi. Support for track numbers is written in Nepomuk Collection. Once Nepomuk indexing improves ( the ongoing work by Vishesh Handa ), we can expect betterr metadata. 

Changing status to resolved as it is more of a Strigi bug.
Comment 5 Karthik Periagaram 2013-02-10 22:18:56 UTC 
Could we reopen this bug, please?

In kde 4.10, the strigi indexers are gone and nepomuk clearly fetches the track number (as can be seen in the Dolphin info panel). However, amarok still does not show the track number in the playlist.

The root cause of this and Bug 310057 might be very similar as they both relate to nepomuk-retrieved properties of a song that don't get read into amarok.

I'm using arch linux packages, so kde 4.10.0, amarok 2.7.0 packages.
Comment 6 Myriam Schweingruber 2013-02-11 09:02:30 UTC 
No, as that is a bug and a regression in Nepomuk in the 4.10 release, not an Amarok bug. Please see bug 314559
Comment 7 Phalgun Guduthur 2013-02-14 18:16:18 UTC 
I can confirm the bug. It is a typo in the code. I'll fix it right away. 
Sorry for the trouble.
Comment 8 Phalgun Guduthur 2013-02-14 18:50:50 UTC 
Git commit 694fd3605bed3cab666eea36e518b2d399c776eb by Phalgun Guduthur.
Committed on 14/02/2013 at 19:37.
Pushed by guduthur into branch 'master'.

Fix typo in query which affected trackNumber
FIXED-IN: 2.8

M  +1    -0    ChangeLog
M  +1    -1    src/core-impl/collections/nepomukcollection/NepomukConstructMetaJob.cpp

http://commits.kde.org/amarok/694fd3605bed3cab666eea36e518b2d399c776eb
Comment 9 Karthik Periagaram 2013-02-15 03:32:50 UTC 
Awesome. Incidentally, does fixing this also cause the nepomuk library to finally start syncing with the local collection? Or would that also require the track length to be the same (in which case, we'll have to wait for bug 310057 to also get fixed)? I've noticed that right now, it basically says that 0 tracks were matched, so nothing was synced.

Thanks for the awesome work!
Comment 10 Phalgun Guduthur 2013-02-15 07:04:56 UTC 
(In reply to comment #9)

The track length would be a Nepomuk issue. I have already ported the plugin to Nepomuk2. 
But I'm planning on a fix on the Nepomuk side to fix this so that stat syncing should atleast work for the users.
Comment 11 Matěj Laitl 2013-05-14 21:25:22 UTC 
Git commit 1081fc2eb3cf0f5ea858ea55257c2033615a031f by Matěj Laitl, on behalf of Phalgun Guduthur.
Committed on 14/02/2013 at 19:37.
Pushed by laitl into branch 'v2.7.x'.

Fix typo in query which affected trackNumber

M  +2    -0    ChangeLog
M  +1    -1    src/core-impl/collections/nepomukcollection/NepomukConstructMetaJob.cpp

http://commits.kde.org/amarok/1081fc2eb3cf0f5ea858ea55257c2033615a031f