GNOME Bugzilla – Bug 689517
Item's placeholder status not unset after uploading
Last modified: 2012-12-11 10:29:04 UTC
After creating a Playlist and uploading the DIDL_S file, there is not URI property in the object that allow to download the DIDL_S. More over, the ImportURI property is still present.
Just a quick comment. The fact that the ImportURI property is still present after the upload isn't in itself a problem. DMSs are allowed to reatin this property after the file has been uploaded to allow clients to update the file at a future date. However, the URI should be present after a successful upload as you mention.
which version are you testing, this should be fixed with 6cf1e9
I found the bug with last Friday version. I also test it this morning, same issue. I will recompile Rygel and tell you the result.
Hrm, Friday should have that commit. What are you using for upload, ImportResource or POST?
*** Bug 689511 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > Hrm, Friday should have that commit. What are you using for upload, > ImportResource or POST? I use POST
Hm. Works here. Is it possible to attach the playlist here?
Created attachment 230537 [details] DIDL of the Playlist Item
Created attachment 230538 [details] DIDL_S
Found the problem. If the file is created without ".xml" extension, GIO reports its content-type as text/plain and media-export does not harvest it.
(In reply to comment #10) > Found the problem. If the file is created without ".xml" extension, GIO reports > its content-type as text/plain and media-export does not harvest it. I've created a playlist using .xml extension ->MediaExport-Message: 'file:///home/lferrandis/Music/fa4ee574-e3e0-42fc-b1d9-da7a0da780ac-Test3.xml' harvested The URI still not exist and delete still not delete the file.
ok, so we have a two-part problem, investigating.
Second part is that the parsing of the playlist fails since the items don't have a "restricted" attribute. The question is: should gupnp_media_collection_add_item already set that (and to what, TRUE or FALSE) or is this the task of the application? DLNA mandates the presence of restricted.
Created attachment 230568 [details] [review] media-export: Handle text/plain DIDL_S playlists don't need to start with <?xml, so if a client does not upload a playlist file with a .xml extenstion, shared-mime-info maps this to text/plain, so we try those as well.
(In reply to comment #13) > Second part is that the parsing of the playlist fails since the items don't > have a "restricted" attribute. > > The question is: should gupnp_media_collection_add_item already set that (and > to what, TRUE or FALSE) or is this the task of the application? > > DLNA mandates the presence of restricted. I set it on the playlist item, not on each item of the playlist. I take example on test-media-collection.c, where protected was not set for each item. I don't think gupnp_media_collection_add_item already add this property. If it's mandatory, maybe it will be safer if this API set this property instead of the application.
Created attachment 230744 [details] [review] Set items to 'restricted' in MediaCollection
Forgot to bz push. This is on master now in both projects.