Summary: | no track number in Nepomuk Collection | ||
---|---|---|---|
Product: | [Applications] amarok | Reporter: | Tomasz Meresiński <tomasz> |
Component: | Collections/Nepomuk | Assignee: | 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
I can reproduce this in v2.6.90-26-gbcdd84c The tracks in nepomuk collection doesnt really have any track numbers. Setting status correctly. 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. 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. No, as that is a bug and a regression in Nepomuk in the 4.10 release, not an Amarok bug. Please see bug 314559 I can confirm the bug. It is a typo in the code. I'll fix it right away. Sorry for the trouble. 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 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! (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. 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 |