Bug 315676

Summary: Nepomuk misreports mp3 track length
Product: [Unmaintained] nepomuk Reporter: Michael D <nortexoid>
Component: generalAssignee: Nepomuk Bugs Coordination <nepomuk-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: kde, me, nepomuk-bugs
Priority: NOR    
Version: 4.10.0   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: sample-mp3

Description Michael D 2013-02-23 10:42:12 UTC
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
Comment 1 Vishesh Handa 2013-02-23 18:38:33 UTC
Please upload any one of those mp3 files so we can index it ourselves and see.
Comment 2 Michael D 2013-02-23 18:56:23 UTC
Created attachment 77533 [details]
sample-mp3

The track length is reported as 00:03.
Comment 3 Ignacio Serantes 2013-03-17 18:47:23 UTC
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
Comment 4 Michael D 2013-03-17 19:15:31 UTC
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?
Comment 5 Ignacio Serantes 2013-03-17 19:38:30 UTC
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.
Comment 6 Vishesh Handa 2013-03-17 19:42:19 UTC
(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.
Comment 7 Michael D 2013-03-17 19:52:09 UTC
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.
Comment 8 Ignacio Serantes 2013-03-17 21:18:50 UTC
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 . }

}
Comment 9 Michael D 2013-03-17 21:41:24 UTC
I apologize for being thick, but I don't know how to run that query. Not from a terminal, I suppose.
Comment 10 Ignacio Serantes 2013-03-17 23:20:50 UTC
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
Comment 11 Vishesh Handa 2013-03-21 00:57:37 UTC
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
Comment 12 Michael D 2013-03-23 20:15:57 UTC
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.
Comment 13 Christoph Feck 2013-04-17 10:34:30 UTC
Michael, any update?
Comment 14 Michael D 2013-04-17 11:28:23 UTC
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.