Bug 84051

What are the legal implications of recording streams?

IANAL, but there exist streams which may be legally recorded (e.g. our LUG brodcasts all lectures so people who can't attend can listen to them online). Of course in order to be pedantic, one could just pop up a message saying that some streams may be subject to recording and copying restrictions etc.
The recording infrastructure would not have to be available for streams only - something generic like the XMMS disk writer plugin would also be nice.

I would REALLY like to see this functionality, too.

*** Bug 90549 has been marked as a duplicate of this bug. ***

it would be wonderful !! Kaffeine already do that, but I will be very happy to see this nice feature in my preferred audio player.

Regarding the 'legality' of recording...
As noted there are plenty of streams where recording is a not a problem.  This is a classic 'VCR problem'.  Just b/c some body will use it to illegaly record something, does not mean there should be no VCR :-)

Now back to the bug topic.
StreamRipper (http://streamripper.sourceforge.net/) does this and has a plugin for XMMS.  But I'd much prefer an integrated 'record' button (just like TIVO :-)

I would like to see a similar integration of StreamRipper in amaroK as it is done in StreamTuner (by the way, it would be great if amaroK would get all the features of StreamTuner).

*** Bug 105184 has been marked as a duplicate of this bug. ***

About adding a record button: usually I do not want to record whole streams, but I would like to be able to record some songs. The problem with hitting the record button while the song is playing is that it records only the end of the song. Thus  some kind of a buffer and a way to cut the ends of the recording would be needed.

Some ideas for a streamripper:

- Configurable if a stream should be "prebuffered" so you can hit the record-button ervery time in a song.

- 2 record-buttons: Record currend song and record stream (untill record is deselected)

- Some stations don't seam to send the song-informations at the current time so an option would be to record more music to an song and in a seperate file the cut-marks when the song-informations where send. I'll make a mockup the next days to show my Idea.

Created attachment 12847 [details]
add streamripper support (stream recording)

This patch add support for recording streams throuh very simple UI 
changes. (It also contains my previous patch that allow to enable/disable 
automatic score computation + a one liner fix for bug 
http://bugs.kde.org/show_bug.cgi?id=110298)

I added a record button next to the play button. This button is enabled only 
when the user plays a stream. 
The recording is automatically stopped when:
- pausing
- playing next/prev track
- stop
- pushing the record button

To record the stream, streamripper launched with fork/exec() with the correct 
arguments. Maybe there is a nicer way to launch external program using KDE 
Libs but since I just have 4 days of KDE/QT experience, I don't know :). The 
record action is also present in the action menu and the systray. Start and 
stop recording will trigger a message in the OSD.

Another possiblity to record streams would be to use the save function of the 
xine engine (appending #save:file to the url, kaffeine uses it) but it has 
some inconvenients (see below) :

streamripper:

+ works with all engines
+ able to save individual songs from streams (only mp3 for now)
+ need 2x the bandwith one stream for amarok playing and one for streamripper
- dont't support all streaming formats, notably wma and real audio streams

xine-engine:

+ able to save all supported streams by the engine
- specific to an engine
- not able to save individual songs

So with this patch only mp3 and ogg streams (and also some aac stream) are 
saved. I think this cover 90% of the uses.

I added new config panel called "Recording". For now it just allows to specify 

the directory where streams are saved. It defaults to the user's home 
directory.

The patch is against 1.2.3

previous patch is against 1.3.2 not 1.2.3 !

Here's some info to apply it:

1. get the amarok 1.3.2 tarball
2. follow the instruction to get the SVN version on the page 
http://amarok.kde.org/amarokwiki/index.php/Installation_HowTo#Building_SVN_amaroK 
until the "svn up amarok" step 
We will not compile the SVN version, It's just to get the script that 
regenerate configure & friends.
In the multimedia directory remove the amarok directory and untar the amarok 
1.3.2 archive.
3. put the patch in the multimedia directory then apply it:
        
cd amarok-1.3.2
patch -p1 < amarok-streamripper.diff
cd ..

4. run make -f Makefile.cvs to regenerate configure
5. configure && make && make install
6. install streamripper if you don't have it

1) Please don't combine patches for multiple features. We can't accept that. 
Make separate patches instead.

2) A patch against 1.2.x is unfortunately useless. Create patches against the 
SVN version.

Created attachment 12851 [details]
add streamripper support (stream recording)

Redone the patch to contain only one modification (streamripper integration)
and to apply on amaroK SVN. New files Options9.ui and Options9.ui.h must be put
in amarok/src

Created attachment 12852 [details]
add streamripper support (stream recording)

oops wrong file type

Very nice!
I patched the source and remerged the package successfully. (Gentoo Linux).
How should I start "streamripper"?

Regards,
/Karim

On Tuesday 04 October 2005 20:27, Michael Pujos wrote:
[bugs.kde.org quoted mail]

On Wednesday 05 October 2005 16:58, Karim Ryde wrote:
[bugs.kde.org quoted mail]

It is started by amarok when you hit the record button and stopped when you 
stop recording. The streams are saved in the directory you specified in the 
option panel ($HOME by default)

The record button is disabled. And I've set a location for storage.

On Wednesday 05 October 2005 17:10, Michael Pujos wrote:
[bugs.kde.org quoted mail]

Created attachment 12914 [details]
streamripper support

updated patch:

- more robust
- use KProcess instead of fork/exec to control streamripper
- display an error popup if streamripper can't be launch (not installed for
example)
- record button state is affected by keyboard record shortcut
- correct record state is streamripper dies ungracefully
- possible to record again after pause

note that to have the record icons you need to have kaffeine installed for know

Any interest in merging my patch that had streamripper support into 1.4 ?

Here's one more reminder about this patch I did dome time ago that add stream recording support via streamripper launched with a record button next to the play button. It works very well, is unobtruvisive, robust and independent of a sound engine and took me some time to implement and I'd like to see it integrated in 1.4 and this bug has over 237 votes so the functionality would make a few people happy.

So from the powers who decide is it :

- yes 
- maybe, we'll try it
- no
- not before amarok 4 using KDE 5
- no, ever
- go away!

Thanks !

We just finished discussing this patch. We decided that this solution to the "stream rip" problem would be best put into a script, outside of the handy button there isn't much reason for this to be in amaroK proper. And allowing scripts to add buttons is probably a noble goal regardless.

So stream ripping really has to be a engine-specific thing.

Hopefully this script exists - otherwise it would be sad if a working patch for a problem with so many votes is just not used because there was a differet decission. I'm not good enough to discuss wether this feature should be realised using a script or a path to amarok itself - but I would like to see this feature.

If you go engine specific you loose the useful feature of streamripper that split the stream into individual files with the correct title extracted from the stream. The Xine engine only knows how to record a stream into a big file. However, using xine engine you can record whatever format is supported by xine, so each solution has its pluses and minuses...
Note that a popular app like streamtuner just use streamripper for recording.

In the meantime I've used my patch in my copy of amarok and "it works for me".

Could it be possible to support xine-recording as well as  streamripper recording depending on the stream and engine? So that the following cases are distinguished by the patch/script:

a. A streamripper-compatible stream is used -> Use Streamripper for recording
b. A non-streamripper-compatible stream is used and xine is used as engine -> use xine for recording
c. A non-streamripper-compatible stream is used and xine is not used as engine: don't offer possiblility to record.

This would be really great since a lot of people (and esspecially me) want to record real audio streams, but not to rip music but e.g to record talk radio.

Personally I don't see why the patch shouldn't go in. It's quite well coded, makes good use of the EngineObserver pattern, and it doesn't add much code. I do however have some remarks:

* It adds a new option page. I think that's getting a bit too crowded. Starts to remind of the Eudora email client ;)

* Perhaps we shouldn't hardcode usage of StreamRipper. I don't know if there are similar tools out there, but we could make the call configurable, I spose. so instead of "streamripper --options" we could call "$RIPPER --options". What do you think?

* Instead of getenv("HOME") you should use QDir::homeDirPath().

* The patch doesn't follow our coding style strictly. Sometimes it uses (foo) and sometimes ( foo ). amaroK coding style is ( foo ).


Generally I would like to see the patch committed. After all it's been a long time wish of our users.

> Personally I don't see why the patch shouldn't go in. It's quite well
> coded, makes good use of the EngineObserver pattern, and it doesn't add
> much code. I do however have some remarks:
>


Thanks for your support !


> * It adds a new option page. I think that's getting a bit too crowded.
> Starts to remind of the Eudora email client ;)
>


I see what you mean! but we'll stiil far of konqueror settings page crowded !

> * Perhaps we shouldn't hardcode usage of StreamRipper. I don't know if
> there are similar tools out there, but we could make the call configurable,
> I spose. so instead of "streamripper --options" we could call "$RIPPER
> --options". What do you think?


AFAIK there is no other tool like streamripper. Even on Win32 streamripper is 
usually used for this task

>
> * Instead of getenv("HOME") you should use QDir::homeDirPath().
>


Did not know that one since it was my first stab at KDE coding

> * The patch doesn't follow our coding style strictly. Sometimes it uses
> (foo) and sometimes ( foo ). amaroK coding style is ( foo ).
>
>
> Generally I would like to see the patch committed. After all it's been a
> long time wish of our users.


I'd like to have it too...Why not commit it and eventually replace it by 
something else (external scripts or whatever) later when it exists ?


Michael

On Wednesday 16 November 2005 14:39, Tobias Niwi wrote:
> Could it be possible to support xine-recording as well as  streamripper
> recording depending on the stream and engine? So that the following cases
> are distinguished by the patch/script:


No, I don't think we will add engine specific recording code. It's just too 
much work to port this to all of our engines, and it's not good if the 
engines have vastly different feature sets. Also too much code bloat.

On Wednesday 16 November 2005 14:55, Michael Pujos wrote:
> I'd like to have it too...Why not commit it and eventually replace it by
> something else (external scripts or whatever) later when it exists ?


Well no, in its current form the patch can't go in. I've actually just looked 
at the option page you've added, and I gotta say it's ridiculous. A whole 
page for one KLineEdit.

After discussing with my fellow dev Sebr, I'm tending to think the script 
approach may be more suitable. Part of your patch could go it (the observer 
stuff), and the ScriptManager could have a new notification. This way we 
don't have to add any extra options to amaroK, and you could write the thing 
in Ruby, which is nice.
 

> On Wednesday 16 November 2005 14:55, Michael Pujos wrote:
> > I'd like to have it too...Why not commit it and eventually replace it by
> > something else (external scripts or whatever) later when it exists ?
>
> Well no, in its current form the patch can't go in. I've actually just
> looked at the option page you've added, and I gotta say it's ridiculous. A
> whole page for one KLineEdit.


Huh yeah. 

>
> After discussing with my fellow dev Sebr, I'm tending to think the script
> approach may be more suitable. Part of your patch could go it (the observer
> stuff), and the ScriptManager could have a new notification. This way we
> don't have to add any extra options to amaroK, and you could write the
> thing in Ruby, which is nice.
>
>


Alright do as you wish, I'm not caring too much anymore. Sure a complicated 
solution requiring a new VM and more memory just to record a stream is 
needed, how couldn't I see that ?  I think it's kind of impossible to have a 
significant patch in amaroK if you're not friends with devs because there's 
almost 0 chance they'll like the way you implement things since everyone has 
a different opinion. You could as well put on amarok's page you will accept 
only small patches for bugs if it's no more than 10 lines. At least I learned 
a thing or two.

I understand your frustration: I once made a suggestion to the amarok team for a feature enhancement and got a rude response which actually came to insults that really put me off using amarok. I don't use it anymore - Rhythmbox is much more user friendly, although it lacks many of amarok's features, and their developers appreciate constructive criticism and seem more open to their users. Amarok is a great player though but I much prefer Rhythmbox for user friendliness. Perhaps your patch could be ported to Rhythmbox.... 

We are sincerely apologetic that we make some of out bug reporters feel this way - however please understand that the developer's might not always agree with you.  On the contrary, here would be a script for triggering stream recording:

------->8------------
#!/usr/bin/env ruby

while 1 
    input = gets
    input.chomp!("\n")
    if input == "engineStateChange: record"
        stream = `dcop amarok player path`
        `streamripper #{stream}`
    end
end
------->8------------

Now, i fail to see how your patch is smaller than that, or how it does anything different? It monitors the engine, and then forks a streamripper instance.

On Wednesday 16 November 2005 21:53, Seb Ruiz wrote:
[bugs.kde.org quoted mail]


Apologies accepted but I don't think I'll do some work on amaroK anymore. For 
what it's worth some weeks ago I looked at bugs I could fix. 

> ------->8------------
> #!/usr/bin/env ruby
>
> while 1
>     input = gets
>     input.chomp!("\n")
>     if input == "engineStateChange: record"
>         stream = `dcop amarok player path`
>         `streamripper #{stream}`
>     end
> end
> ------->8------------
>
> Now, i fail to see how your patch is smaller than that, or how it does
> anything different? It monitors the engine, and then forks a streamripper
> instance.
>
>
>


Sure but :

- it does not add automatically a record button to amarok that can be 
triggered via the menu or the systray
- it does not automaticcaly stop recording if you go to next track, hit pause 
etc...they are some corner cases that my patch address
- path must be coming from some user preference right ?
- you need ruby for this ..it means a new dependency to amaroK + more RAM 
needed just to launch a program!
- doesn't handle streamripper dieing durring ripping or not launching at all 
and having always the record button state correct
- it does not notify the OSD


Well, there's a few more ruby lines required I guess. 

On Thursday 17 November 2005 08:13, Michael Pujos wrote:
> - it does not add automatically a record button to amarok that can be
> triggered via the menu or the systray

use "dcop amarok script addCustomMenuItem Record"

> - it does not automaticcaly stop recording if you go to next track, hit
> pause etc...they are some corner cases that my patch address

just add another line
if input == "engineStateChanged:trackChanged"

> - path must be coming from some user preference right ?

easy to implement a small dialog for this, configurable through the script 
manager

> - you need ruby for this ..it means a new dependency to amaroK + more RAM
> needed just to launch a program!

It's not a dependency, just install it if required.  hardly use any more ram 
than your patch will increase the binary size/footprint.  its a two way 
argument.

> - doesn't handle streamripper dieing durring ripping or not launching at
> all and having always the record button state correct

trap the SIGTERM signal

> - it does not notify the OSD

This can't be done, but it wouldn't be a bad option to use a statusbar 
popupMessage.

On Wednesday 16 November 2005 22:24, Seb Ruiz wrote:
[bugs.kde.org quoted mail]

There's probably more code to add a shortcut and an Icon I suppose

>
> > - it does not automaticcaly stop recording if you go to next track, hit
> > pause etc...they are some corner cases that my patch address
>
> just add another line
> if input == "engineStateChanged:trackChanged"
>


won't handle pause, stop

> > - path must be coming from some user preference right ?
>
> easy to implement a small dialog for this, configurable through the script
> manager
>
> > - you need ruby for this ..it means a new dependency to amaroK + more RAM
> > needed just to launch a program!
>
> It's not a dependency, just install it if required.  hardly use any more
> ram than your patch will increase the binary size/footprint.  its a two way
> argument.
>


If I launch a while(1) ; program ruby I see a VmRss or 1.3Mb and VmSize of 
3Mb. Sure my patch make amarok mem usage grow by 1.3Mb. Know you may say this 
not significant and everybody a 512Mb of RAM anyway...

> > - doesn't handle streamripper dieing durring ripping or not launching at
> > all and having always the record button state correct
>
> trap the SIGTERM signal
>
> > - it does not notify the OSD
>
> This can't be done, but it wouldn't be a bad option to use a statusbar
> popupMessage.



In the end, to make things robust you'll have pretty much as many line as I 
have in my patch :)

There is now a simple plugin that can has much of this functionality.
http://kde-apps.org/content/show.php?content=32842
However it would be good if it were able to be controlled through the user interface. So maybe this should be recategorized as, "Plugins should be able to add elements to the user interface."

Hi,
It would be nice if the ripper was integrated with the proposed last.fm stream support (http://bugs.kde.org/show_bug.cgi?id=111983) so you can record the last.fm streams. Skipping a song should not save half that song.

*** Bug 133250 has been marked as a duplicate of this bug. ***

Please integrate streamripper into Amarok. :)

Same here: I am listening to radio via the internet and would like to record some broadcasts, if possible timed / scheduled. The last entry has been done quite some time ago. What's the status of this plugin / feature?

@Oliver Zimmermann: perhaps this helps you. http://de.kde-apps.org/content/show.php/RecordRadio?content=32842

Please add that save-stream button.  I don't care how it's done, through streamripper or whatever.  I'm just astonished it hasn't been done already.

*** Bug 149250 has been marked as a duplicate of this bug. ***

Yup, I also think it would be nice to have!

It's probably best to leave stream ripping up to the professionals (i.e. streamripper devs) and as Amarok only access external applications this is a script's job.

Also we offer a way to integrate menu options into the playlist's right button menu.
So, for example:
* you listen to a stream
* like it
* right click its PL item
* select streamrip
* script does what ever it's willing to do

Therefore I'm closing this report.

*** Bug 167692 has been marked as a duplicate of this bug. ***