GNOME Bugzilla – Bug 631987
Podcasts marked as read-only
Last modified: 2020-03-17 08:51:29 UTC
When a podcast is downloaded it is marked as read-only, if you then try to sync the podcasts to an external media device it generates an error report. Podcasts should get both read and write permissions. current work around: Run chmod 777 ~/Podcasts/ in a terminal.
Podcast files are marked read-only by design. Quoting Mike Urbanski in another report : "When downloaded, podcast files are marked read-only. When an item's parent feed is deleted, its enclosure directory is also deleted if no RW files are present. If a deleted feed's enclosure directory contains both RO and RW files, the RO files are deleted while RW files are left untouched." What is exactly the error caused by this ? What kind of external device ? Mass storage, MTP or Apple device ? Maybe we should mark podcast files as RW when transferring to a device.
The device is the SD card on an HTC G2 Android phone. When I sync podcasts with the phone if they are marked as RO 2 things happen. 1.) banshee generates an error report 2.) The files are copied to the SD card, but they lose parts of the IDv3 tags. If I then unmount and remount the phone the synced podcasts show up in the general music section of the phone. If however, syncing is completed with files marked as RW everything goes smoothly and podcast files are shown in a podcast section in the device.
I've seen similar behavior with Banshee 1.8 with a mass storage device (Sansa Clip+). - Drag a downloaded podcast over to the device - The podcast transfers to the device - Once it's completed, an error appears under the left-side menu icon for the device -- 'Error opening file '/media/Sansa Clip+/Podcasts/... :Permission Denied' The file does indeed transfer to the device, but is always marked read only. Since Banshee is spitting a 'Permission Denied' error, it appears it can't do what it needs to do with the file. So if marking everything read-only is by design, it seems that design didn't account for Banshee trying to work with devices and needing the very permissions it's designed not to give.
Created attachment 173042 [details] error after transferring podcast to device Here's a screenshot of the 'Permission Denied' error that appears after transferring a podcast to a device. The file can't be found on the device inside of Banshee at that point, although the transfer did occur. Disconnect the device and connect again, and the podcast can be seen on the device from within Banshee, when it couldn't be seen after it was originally transferred.
*** Bug 636099 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > current work around: Run > chmod 777 ~/Podcasts/ > in a terminal. This is obviously dangerous. However, Banshee does indeed seem to have a problem. Hence marking as NEW.
- Standard file rights are -r--r--r-- - If a podcast was transfered to Android a warning in banshee occurred that banshee can not open the transferred file. (file was copied) - The copied file do not appear in the phone podcast list from banshee - Changing file rights to -rwxrw-rw- before transfering than it works.
Created attachment 194333 [details] [review] Do not set the Podcast to readonly, as this has for me no obvious use. I take a look into the code. There is a line that explicit set the permission of the file to read only. I have no Idea why this line is there... I removed the line (see attached patch) and run this, without any problem.
(In reply to comment #8) I take a look in the log. The line comes from the initial commit of the new podcast code. http://git.gnome.org/browse/banshee/commit/?id=dc8deab08c01cd195a6e784bcae8a212b661324c
Review of attachment 194333 [details] [review]: Thanks for the patch Stefan ! See comment #1 for an explanation why the file are set to be read-only. I'm a bit uncomfortable with applying the change as-is, because it introduces a subtle change in behavior where files that were previously kept would now get deleted. I'm not sure anyone relies on the current behavior though, so I'm open to being reassured and changing my mind :)
I had should first Read, then patch ;) What is the goal of this? Should banshee only files downloaded by banshee delete, but other files remain untouched? The design seems to me, not very solid. It seems for me that, the read only mark is miss used.
Forgive me if I'm wrong (haven't programmed in C for about 6 years) but cant you just change the permissions once the file is loaded into memory e.g. change the permissions when the copy (sync) is done.
This issue affects me as well. I constantly get "Error opening file ...: Permission denied" errors when trying to transfer podcasts to my Android phone. I have to run a chmod on my podcast directory every time before I initiate any transfer. This is obviously not optimal. A better way of handling this needs to be implemented. Using Banshee 2.2 (Daily build) on Ubuntu 11.10.
Sorry, but could someone explain what the current status of this issue is? Is it going to be fixed? It seems from some of the comments that some developers think this is already being done the right way, in which case I'm not sure if there's something I'm supposed to be doing in order to be able to transfer podcasts without errors. I hope the proposed solution is not to run chmod before every transfer. Surely that isn't the end of it.
I am also affected by this bug, and also can't see the point in setting the files to be RO after downloading them. IMHO the nature of a podcast directory should be dynamic (ie. the contents controlled entirely by the media player) and if I ever wanted to save a particular podcast I'd put it somewhere else ;) If this 'feature' won't go away, why not do it the other way round? If there's any RO files in the enclosure (ie. the ones a user marks as RO when they want to keep them, perhaps done from banshee through the context menu of any particular podcast episode) then don't delete everything, just the RW files. However, we'd still have trouble when trying to transfer a 'saved' podcast to the device. +1 for removal of the line mentioned in <a href="https://bugzilla.gnome.org/show_bug.cgi?id=631987#c10">Comment 10</a>
I am also affected by this bug. As a comment, Daniel's post (Comment 2) suggests that part of the problem may be that banshee attempts to update the IDv3 tags after the files have been transferred as read only, and fails.
Any updates on this bug?
Also affected, trying to transfer podcasts to HTC Desire S
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.