Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1519700 - Rhythmbox database tracks non-media files in $HOME directory
Summary: Rhythmbox database tracks non-media files in $HOME directory
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rhythmbox
Version: 7.5
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Bastien Nocera
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 1519699
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-01 08:46 UTC by Jiri Prajzner
Modified: 2018-06-12 08:28 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1519699
Environment:
Last Closed: 2018-06-12 08:28:48 UTC


Attachments (Terms of Use)

Description Jiri Prajzner 2017-12-01 08:46:12 UTC
+++ This bug was initially created as a clone of Bug #1519699 +++

Description of problem:
Rhythmbox tracks files that are not relevant to the media files it is able to play and marks them as "ignore".

Version-Release number of selected component (if applicable):
3.4.2

How reproducible:
Always

Steps to Reproduce:
1. grep location .local/share/rhythmbox/rhythmdb.xml | wc -l
2. grep ignore .local/share/rhythmbox/rhythmdb.xml | wc -l
3. 

Actual results:
grep location .local/share/rhythmbox/rhythmdb.xml | wc -l
780
grep ignore .local/share/rhythmbox/rhythmdb.xml | wc -l
629

Expected results:
Rhythmbox doesn't track non-media files

Additional info:
This is really unpleasant discovery and I think that the community should be aware of this and this has to be fixed.

Comment 2 gkrithi8 2017-12-06 13:43:00 UTC
what is the issue you are facing here ?

Comment 3 Jiri Prajzner 2017-12-06 14:32:38 UTC
rhythmbox tracks files in my home dir that have nothing to do with its business. That's a problem, because it should track only media files. If this is not a problem for you, then i don't know why we even bother with filtering.

Comment 4 gkrithi8 2017-12-06 14:42:18 UTC
attach rhythmdb.xml if possible.

Comment 5 Jiri Prajzner 2017-12-06 15:03:13 UTC
some entries from my rhythmdb.xml:
<entry type="ignore">
    <title></title>
    <genre></genre>
    <artist></artist>
    <album></album>
    <location>file:///home/jprajzne/rhythmbox/features/steps/steps.py</location>
    <mtime>1463401779</mtime>
    <last-seen>1464085206</last-seen>
    <date>0</date>
    <media-type>application/octet-stream</media-type>
  </entry>
<?xml version="1.0" standalone="yes"?>
 <rhythmdb version="2.0">
  <entry type="ignore">
    <title></title>
    <genre></genre>
    <artist></artist>
    <album></album>
    <location>file:///home/jprajzne/template.html</location>
    <mtime>1448060208</mtime>
    <last-seen>1464085164</last-seen>
    <date>0</date>
    <media-type>application/octet-stream</media-type>
   </entry>


... and so on.
it actually ignores files that it could track, such as album covers:
  <entry type="ignore">
    <title></title>
    <genre></genre>
    <artist></artist>
    <album></album>
    <location>file:///home/jprajzne/Music/Grant%20Green/1961%20-%20Reaching%20Out/COVER.jpg</location>
    <mtime>1350070630</mtime>
    <date>0</date>
    <media-type>application/octet-stream</media-type>
  </entry>

Comment 7 Bastien Nocera 2018-06-08 14:59:12 UTC
What's the output of:
gsettings get org.gnome.rhythmbox.rhythmdb locations

Comment 8 Jiri Prajzner 2018-06-11 08:57:40 UTC
before first launch:
@as []

after first launch:
['file:///home/test/Music']

Comment 9 Bastien Nocera 2018-06-11 14:38:35 UTC
I've tried to reproduce the problem with both the stock 3.4.2 release, and the latest git master of rhythmbox, and couldn't.

Each time I ran a test I removed the ~/.local/share/rhythmbox/ directory, and reset the "locations" key with:
gsettings reset org.gnome.rhythmbox.rhythmdb locations

$ grep '<location>' rhythmdb.xml  | grep -v $HOME/Music | wc -l
0

I'm guessing that something else added new items in the database. Please provide exact reproducer steps, as I cannot reproduce this problem.

Comment 10 Bastien Nocera 2018-06-11 14:41:39 UTC
(In reply to Jiri Prajzner from comment #5)
> it actually ignores files that it could track, such as album covers:

Why would it "track" album covers? Are you sure you're not misunderstanding what those entry types mean? The rhythmbox database isn't supposed to be read by users, and you might be inferring behaviour based on names without checking what the source code does with those.

(Every file type that isn't an audio file is marked as "ignored", cover art doesn't need to be tracked, and will be fetched on an as-needed basis)

Comment 11 Jiri Prajzner 2018-06-12 08:03:30 UTC
can't actually reproduce it either.
on the tracking of album art/covers, just a thought that it may not try to download them again, but i don't know how that works. feel free to discard.

Comment 12 Bastien Nocera 2018-06-12 08:28:48 UTC
(In reply to Jiri Prajzner from comment #11)
> can't actually reproduce it either.

Good :)

> on the tracking of album art/covers, just a thought that it may not try to
> download them again, but i don't know how that works. feel free to discard.

The rhythmdb database only tracks media files, so it knows which one it already scanned, whether it needs to scan them again because they changed (you updated the tags for example).

Cover art is not associated with media files at this point (indexing), but only when a media file is being played, when the art-search plugin's "local" backend will scan the directory to find the cover for the track or album. So the non-media files are rightfully ignored. It will keep rhythmbox from trying to index them again.


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