After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 704317 - Files that are accessible via "Files & Folders" not available in virtual folders
Files that are accessible via "Files & Folders" not available in virtual folders
Status: RESOLVED FIXED
Product: rygel
Classification: Applications
Component: MediaExport plugin
git master
Other Linux
: Normal normal
: ---
Assigned To: Jens Georg
rygel-maint
: 692712 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-07-16 12:48 UTC by Jussi Kukkonen
Modified: 2013-09-29 11:40 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
media-export: Fix GstDiscoverer error handling (2.10 KB, patch)
2013-09-28 15:56 UTC, Jens Georg 		committed Details | Review

Description Jussi Kukkonen 2013-07-16 12:48:10 UTC 
I have a few files that are browsable through "Files & Folders", but do not appear in the virtual folder. Unfortunately they are part of the dlna test set so I can't upload (I'll try to debug this myself later).

All files in Audio/AAC_ISO_320 directory appear in the directory structure but browsing to "Music/All" does not show them. I suppose it should.
Comment 1 Jussi Kukkonen 2013-07-16 14:29:37 UTC 
Found a bug in rygel-media-export-metadata-extractor.vala: the Discoverer results are considered a bitfield which they do not seem to be: it's just an enum based on a quick look at gstreamer code. This leads to a wrong debug message if discover fails (in my case claims to timeout when it's failing because of missing plugins). Then rygel for some reason offers transcoded versions in the DIDL, and cant actually transcode (again, because of missing gstreamer plugin).

I'll see if fixing the discovery result handling fixes at least some issues here.
Comment 2 Jens Georg 2013-07-17 07:52:07 UTC 
I've the files available. The bitfield thing might come from porting it from old gupnp-dlna to GstDiscoverer.

We don't actually check whether we have all plugins available to do the transcoding because there's several possibilities to do that and in the end encodebin decides which elements it uses. And we could check sort of reliably only for the encoding path since we don't know what the input files will be.
Comment 3 Jussi Kukkonen 2013-07-17 08:34:15 UTC 
Yeah that makes sense. A bit annoying from usability POV but makes sense.


I guess I'll do this for the result values:

  GST_DISCOVERER_OK               = 0,
Use the discovered info 


  GST_DISCOVERER_URI_INVALID      = 1,
  GST_DISCOVERER_ERROR            = 2,
Call error() (and create the GLib.Error parameter if needed).


  GST_DISCOVERER_TIMEOUT          = 3,
  GST_DISCOVERER_BUSY             = 4,
  GST_DISCOVERER_MISSING_PLUGINS  = 5
Call extract_basic_information() and continue with that -- but print some useful debug.
Comment 4 Jens Georg 2013-07-26 16:13:40 UTC 
Sounds good
Comment 5 Jens Georg 2013-09-28 15:40:00 UTC 
*** Bug 692712 has been marked as a duplicate of this bug. ***
Comment 6 Jens Georg 2013-09-28 15:56:42 UTC 
Created attachment 255987 [details] [review]
media-export: Fix GstDiscoverer error handling

The code was ported from old GUPnPDLNADiscoverer code under the assumption
that the error handling is the same (a bitfield), but it isn't.
Comment 7 Jens Georg 2013-09-29 11:40:11 UTC 
Attachment 255987 [details] pushed as b297ef1 - media-export: Fix GstDiscoverer error handling