Both KDE 4.10 and previous versions misreport mp3 track length. It says of all my tracks that they are under 10 seconds in length, usually between 2-6 seconds. Reproducible: Always Steps to Reproduce: 1. Index mp3s 2. Check the indexed metadata for track length Actual Results: Nepomuk misreports track length Expected Results: Nepomuk correctly reports track length
Please upload any one of those mp3 files so we can index it ourselves and see.
Created attachment 77533 [details] sample-mp3 The track length is reported as 00:03.
I test the uploaded file and nepomuk is reporting the right length: 00:03:35. You can use nepomukindexer to review how nepomuk is indexing that file: nepomukindexer --data moloko\ -\ sing\ it\ back.mp3 In that caos the relevant infomation for this case is the next: ( QUrl( "http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#duration" ) , QVariant(int, 215) ) 215 seconds = 3:35 minutes
Running that command returns the following: AAAAAgAAAANfOmEAAAAKAAAAQWh0dHA6Ly93d3cuc2VtYW50aWNkZXNrdG9wLm9yZy9vbnRvbG9naWVzLzIwMDcvMDMvMjIvbmZvI2NoYW5uZWxzAAAAAgAAAAACAAAAPmh0dHA6Ly93d3cuc2VtYW50aWNkZXNrdG9wLm9yZy9vbnRvbG9naWVzLzIwMDkvMDIvMTkvbm1tI2dlbnJlAAAACgAAAAAIAE0AaQBzAGMAAAAvaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zI3R5cGUAAAARAAAAAENodHRwOi8vd3d3LnNlbWFudGljZGVza3RvcC5vcmcvb250b2xvZ2llcy8yMDA5LzAyLzE5L25tbSNNdXNpY1BpZWNlAAAAQWh0dHA6Ly93d3cuc2VtYW50aWNkZXNrdG9wLm9yZy9vbnRvbG9naWVzLzIwMDcvMDMvMjIvbmZvI2R1cmF0aW9uAAAAAgAAAADXAAAAR2h0dHA6Ly93d3cuc2VtYW50aWNkZXNrdG9wLm9yZy9vbnRvbG9naWVzLzIwMDcvMDMvMjIvbmZvI2F2ZXJhZ2VCaXRyYXRlAAAAAgAAAfQAAAAAPGh0dHA6Ly93d3cuc2VtYW50aWNkZXNrdG9wLm9yZy9vbnRvbG9naWVzLzIwMDcvMDEvMTkvbmllI3VybAAAABEAAAAAS2ZpbGU6Ly8vaG9tZS9taWNoYWVsL011c2ljL1ZhcmlvdXMvTW9sb2tvL21vbG9rbyUyMC0lMjBzaW5nJTIwaXQlMjBiYWNrLm1wMwAAAEFodHRwOi8vd3d3LnNlbWFudGljZGVza3RvcC5vcmcvb250b2xvZ2llcy8yMDA3LzAxLzE5L25pZSNtaW1lVHlwZQAAAAoAAAAAFABhAHUAZABpAG8ALwBtAHAAZQBnAAAAPmh0dHA6Ly93d3cuc2VtYW50aWNkZXNrdG9wLm9yZy9vbnRvbG9naWVzLzIwMDcvMDEvMTkvbmllI3RpdGxlAAAACgAAAAAYAFMAaQBuAGcAIABpAHQAIABCAGEAYwBrAAAAQ2h0dHA6Ly93d3cuc2VtYW50aWNkZXNrdG9wLm9yZy9vbnRvbG9naWVzLzIwMDcvMDMvMjIvbmZvI3NhbXBsZVJhdGUAAAACAAAArEQAAABCaHR0cDovL3d3dy5zZW1hbnRpY2Rlc2t0b3Aub3JnL29udG9sb2dpZXMvMjAwOS8wMi8xOS9ubW0jcGVyZm9ybWVyAAAAEQAAAAADXzpiAAAAA186YgAAAAIAAAAvaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zI3R5cGUAAAARAAAAAEBodHRwOi8vd3d3LnNlbWFudGljZGVza3RvcC5vcmcvb250b2xvZ2llcy8yMDA3LzAzLzIyL25jbyNDb250YWN0AAAAQWh0dHA6Ly93d3cuc2VtYW50aWNkZXNrdG9wLm9yZy9vbnRvbG9naWVzLzIwMDcvMDMvMjIvbmNvI2Z1bGxuYW1lAAAACgAAAAAMAE0AbwBsAG8AawBv I have already reindexed everything once, but perhaps the old (pre 4.10) indexer (strigi?) is still indexing. Is there any way to check this?
Only this output? That kind of information is displayed and the end. If you scroll up are there more information? To discover if one file is indexed with new indexer or strigi you could use the next SPARQL query: SELECT * WHERE { ?r nie:url ?v . FILTER(REGEX(?v, "<file_name>"^^xsd:string, 'i')) optional { ?r kext:indexingLevel ?level . } } but you need to replace all spaces with %20 so for: moloko - sing it back.mp3 you must write: moloko%20-%20sing%20it%20back.mp3 if a value of 2 is displayed in column level then file is indexed with new indexer.
(In reply to comment #4) > Running that command returns the following: > Please enable debug messages via kdebugdialog. Also, if you do nepomukindexer <fileName> it will discard the old data, and reindex the file. So, then there is no chance of the old-strigi data being present.
Yes, only this output. In fact, I just ran nepomuk cleaner (it did some stuff for a few minutes), reindexed the song using "nepomukindexer "moloko - sing it back.mp3"", and reran the command "nepomukindexer --data moloko\ -\ sing\ it\ back.mp3". It returned exactly the same output, and Dolphin shows a track length of 3 seconds still. I removed some legacy stuff like strigi (I hope I got it all). I'll try reindexing again to see if that helps.
Next query will display the information stored in Nepomuk's database so you can determine if the bug is in the indexer or in Dolphin. SELECT * WHERE { ?r nie:url ?v . FILTER(REGEX(?v, "moloko%20-%20sing%20it%20back.mp3"^^xsd:string, 'i')) optional { ?r kext:indexingLevel ?level . } optional { ?r nfo:duration ?duration . } }
I apologize for being thick, but I don't know how to run that query. Not from a terminal, I suppose.
In Nepomuk Shell (NepSak) you could execute SPARQL queries. Probably this tool is available in your distribution repository. http://kde-apps.org/content/show.php?content=135356
On Sunday 17 Mar 2013 21:41:24 Michael D wrote: > https://bugs.kde.org/show_bug.cgi?id=315676 > > --- Comment #9 from Michael D <nortexoid@gmail.com> --- > I apologize for being thick, but I don't know how to run that query. Not > from a terminal, I suppose. Not at all. You aren't a developer, you wouldn't know it. We should have provided the extra info. As Ignacio mentioned there is an application you can use, or you can use a command called nepomukcmd. It can be found over here [1] In order to run a query, you will have to type - $ nepomukcmd query 'insert query over here' [1] http://techbase.kde.org/Development/Tutorials/Metadata/Nepomuk/TipsAndTricks#nepomukcmd
Thanks for the clarification. I've since upgraded to an SSD and installed my distro anew. I have to index my files again to see if the problem persists. I'm hoping a fresh install to KDE 4.10.1 (rather than an upgrade from 4.9) solves the problem.
Michael, any update?
Running nepomukindexer "moloko - sing it back.mp3" now shows 215 seconds, which is correct. So somewhere between 4.10.0 and 4.10.2, indexing got fixed on my system. Bug closed, I guess.