Bug 130929 - If directly transfered to media-player, files are named xyz.stream instead of xyz.mp3
Summary: If directly transfered to media-player, files are named xyz.stream instead of...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: amarok
Classification: Applications
Component: Collections/Media Devices (show other bugs)
Version: 2.0-SVN
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-16 19:29 UTC by S. Burmeister
Modified: 2012-08-05 13:41 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description S. Burmeister 2006-07-16 19:29:25 UTC
Version:           1.4.1 (using KDE KDE 3.5.3)
Installed from:    SuSE RPMs
OS:                Linux

If one drags a podcast directly to the media-player and did not sownload the podcast to the harddisk before that, a file named xyz.strem is transfered to the media-player.

This is bad because some mp3-players do not look into the files but just rely on the .mp3 and hence do not recognise the podcasts as playable files.

Expected behaviour would be to transfer the files as xyz.mp3, no matter if they were saved to the harddisk before or not.
Comment 1 Martin Aumueller 2006-07-29 16:43:25 UTC
I guess this happens with vfat media devices? I tested this procedure with ipods w/o any problems.
Comment 2 S. Burmeister 2006-07-29 18:38:45 UTC
Yes this was a vfat-device.
Comment 3 Martin Aumueller 2006-08-22 09:24:16 UTC
Could you please test if this is still the case with 1.4.2 - the handling of file name creating has been changed quite a bit?
Comment 4 S. Burmeister 2006-09-20 20:46:00 UTC
Transfering a podcast directly to the media-player is broken in 1.4.3, so I cannot test it. One can add the podcast to the queue but when I try to transfer it, it is marked as not available.

Downloading first and transfering does work.
Comment 5 Martin Aumueller 2006-10-21 14:21:05 UTC
Could you please check if direct podcast transfer (w/o downloading before) works in current svn? It does for me.
Comment 6 Jeff Mitchell 2006-10-24 17:30:30 UTC
Also, why is the behavior in 1.4.3 a bug?  If a podcast isn't downloaded to the hard disk, why should to be able to transfer it?  It makes sense to me that it would be marked as not available.
Comment 7 S. Burmeister 2006-10-24 18:25:15 UTC
Not really. Why would I have to download a file to the harddisk, just to put it on a removeable media, if it can be done directly. And marking it as not available is not true either, because it is, just that the protocol to be used differs.

In the end there is not much difference between a file only available on a server and a file only available on a USB-harddisk, as long as the "cable", i.e. connection, is online. Nobody would think of marking files played off a USB-harddisk as not available, if it was not saved on the computer's built-in harddisk before transfering it to a media-player.

I do not use svn, but will check with the next release.
http://bugs.kde.org/show_bug.cgi?id=135681
Comment 8 Martin Aumueller 2006-12-28 18:40:35 UTC
1.4.4 was released already some weeks ago. Did you already check if the bug is still present?
Comment 9 S. Burmeister 2007-01-06 10:15:59 UTC
How can I test this, if the bug that podcasts cannot be transfered to the media-player at all, is not yet solved in 1.4.4? (Comment #4)
Comment 10 Lydia Pintscher 2008-08-06 00:45:06 UTC
Alejandro can you please comment on this?
Comment 11 Alejandro Wainzinger 2008-08-06 01:22:30 UTC
Can't say much, except that I agree that copying to the iPod should download the podcast temporarily before copying to the device, just alerting the user to the download.  This will likely get implemented in Akademy, along with podcasts in general for 2.0.

But sorry, no retroactive bugfixes for 1.4 for podcasts.
Comment 12 Alejandro Wainzinger 2008-08-06 01:41:30 UTC
... and so this will be dealt with in 2.0.
Comment 13 Myriam Schweingruber 2012-08-05 13:41:04 UTC
Closing correctly. Solved in Amarok 2.x since quite some time