Re: legality
On 3 April 2011 14:02, James Cook james.c...@bluewin.ch wrote: Hallo All, every since Phil stopped further development of get_iplayer I been wondering about the legality of developing code for get_iplayer. I wonder if by uploading patches we are exposing ourselves to possible legal action.. Does anyone else here wonder about this? Does it depend on the patch? Should we consider some kind of anonimity? Yes, I do wonder about it from time to time, but last time I checked the terms and conditions for accessing both the BBC website and BBC iPlayer, I couldn't see anything that *I* was doing that broke those terms. The relevant terms, provided that nobody here is doing this for commercial purposes, are: for general terms of access to BBC content: http://www.bbc.co.uk/terms/personal.shtml for iPlayer: http://www.bbc.co.uk/terms/additional_iplayer.shtml for the RSS feeds - used for obtaining BBC schedules (and iPlayer content) http://www.bbc.co.uk/terms/additional_rss.shtml and for the podcasts: http://www.bbc.co.uk/terms/additional_podcast.shtml note that get_iplayer is *not* a BBC iPlayer Download Application, so none of those terms apply. There are a couple of areas where things *might* get a bit sticky: - use of iplayer in the name, and graphics that look like the iPlayer logo - clause 3.2.3(d) of the general terms, specifically -- reverse engineering - whether using the publicly-available interfaces on the BBC website constitutes reverse engineering or not, and if it did whether creating and using get_iplayer falls under the terms permitted under the EU directives on interoperability (in my case I argue it does since the BBC choose not to provide a download application which interoperates with my PC which runs linux and xbmc - no, the linux support doesn't work because it relies on having a beefy processor to do stuff that xbmc does in the graphics card) -- attempting to breach copyright/helping others to do so (bear in mind that the BBC has permitted UK residents to view the content they provide, so accessing and using that content is not a breach of copyright) Unfortunately you have to read the terms yourself, take your own legal advice - which you won't find here, and make your own decisions about using and/or contributing to get_iplayer. Incidentally, going for anonymity probably won't work technically, and would simply encourage others to infer that you think you're guilty. disclaimer - I am not a lawyer Jon ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: [PATCH] Re: atomicparsley tagging issue
On 3 April 2011 00:12, Jimmy Aitken jimmy.ait...@gmail.com wrote: I've actually patched my get_iplayer to use eyeD3. On 3 April 2011 11:45, Shevek she...@shevek.co.uk wrote: I personally would prefer not to add any further dependencies to get_iplayer. Nor would I. I'd prefer to move towards fewer dependencies, and perhaps consider adopting a perl-native tagging library. Looks like tagging is going to end up as a long conversation too... Jon ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: [PATCH] Re: atomicparsley tagging issue
On Sun, Apr 03, 2011 at 02:39:04PM +0100, Jon Davies wrote: Nor would I. I'd prefer to move towards fewer dependencies, and perhaps consider adopting a perl-native tagging library. What I'd like to see - and I think this would be a big enough change that this is really more of a suggestion for the download client that gets written for the successor to iPlayer - is a conventionally Unix-like nest of programs that each do one thing, but talk to each other; they could then be connected by a (textual, GUI or web-based) interface. These one things might be, for example: searching the programme listings for specific titles/etc.; taking a single programme ID and converting it to be something to be fed into getrtsp; remuxing and/or transcoding the output from getrtsp; tagging. R ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Broken list threads
On Sun, 2011-04-03 at 17:01 +0100, Andy Waddington (software devel) wrote: Sometime before sending, David Woodhouse typed (and on Saturday 2011-04-02 sent): On Sat, 2 Apr 2011, Jonathan Wiltshire wrote: Some mail clients, usually the ones written with lists in mind, have a shortcut to reply only to the list. In mutt it's Shift-L. Although many people frown upon that feature and consider it extremely rude to drop people from the discussion by using it: http://david.woodhou.se/reply-to-list.html Other people consider it very rude to reply direct to them as well as the list, so that they get the reply twice. Yes. It's a choice between two evils. Which is worse? - To drop someone from the discussion entirely, when they have actively taken part in it already, or - To cause someone to receive two copies of an email. Now consider the fact that it's trivial for people who *really* want to avoid duplicates to filter them out on the receiving end, by dropping the second message that arrives with the same Message-Id. Does that change the choice at all? What works for mailing lists which only allow posts from people subscribed to the list is not the same as those which allow anyone to post. It changes the equation slightly. But don't forget that if a list bars posts from non-subscribers, that just forces people who *occasionally* want to contribute, or who read mail through the archives as Vangelis does, to subscribe and either disable mail delivery, or just filter it into a folder that they almost never look at. So just because the list forces people to subscribe, that doesn't *necessarily* mean that they'll see a message if you drop them from Cc when you're replying to them. Also, typically, it breaks the system by which mailing list messages get filed in their own mailbox (because people filter on the To: field containing the mailing list name, and may not check Cc: and so on. This clogs personal mailboxes). That's just broken filtering; you should never filter on the recipients in the To/Cc headers. They may bear *no* relationship to the actual recipient of the messages, or the reason why *you* are receiving it. One thing that is a universally bad idea is to reply to the sender, and blind CC to the list, so that the list name doesn't get put anywhere that recipients can filter on it... That's incorrect. Compare the two copies of this message that you receive, for example. There are at least three things you could filter on which are *unique* for the copy that arrives through the list. In order of accuracy: The *best* thing to filter on is the SMTP reverse-path, which may appears in a Return-Path: header by the time the message is delivered. It should match get_iplayer-bounces.*@lists.infradead.org. Second best thing is a Sender: header, which will be get_iplayer-boun...@lists.infradead.org. Third (and less reliable than the above two) is a List-Id: header of get_iplayer.lists.infradead.org. This one is less reliable because it fails in the case which might seem obscure, but which does actually happen to me: - You *are* (or have been) subscribed to the list. - You filter the list messages into a folder. - You have mostly lost interest, and never look in that folder. - Someone knows that you don't actively read the list, and sees a message on the list that they *know* you may be interested in. - This 'someone' sends the the message to you. Instead of forwarding it, they 'resend' (or bounce or redirect) it, so the original message is intact for you to reply to. The List-Id: filter would catch that message and drop it into the list folder even though it was sent *personally* to you. Filtering on reverse-path or sender is the only 100% reliable option. -- dwmw2 ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: [PATCH] Re: atomicparsley tagging issue
On 03/04/2011 09:06, James Cook wrote: A configuration mechanism is a good idea, but I think it will have be based a full mapping of get_iplayer fields - MP3 frames - MP4 atoms. I've done this for iTunes, and it's pretty straightforward. I don't think id3v2 can add artwork, but that seems acceptable unless someone knows of another cross-platform ID3v2 command-line tagger that can insert APIC frames. It seems everyone has their own solution, id3v2 is very outdated and you can't set APIC as you say, as well as ... TDRL for example - so I doubt if anyone is really using it (?). It's certainly a dead end, though it works well enough for people like my Windows-user colleagues who just want to download The Archers omnibus and pop it into WMP. There are better libraries out there, but I can't say I have much ambition to concoct a command-line media tagger in C++. Actually its the underlying id3lib which is outdated. I have tweaked these two to get some simple tags (TDRL) working but not for complex tags. I sympathise. The lack of support for useful (according to me) frames finally drove me to eyeD3 and then on to Mutagen. As an iTunes user, I've found it pretty beneficial to have better tagging control, e.g., for managing downloads as podcasts. The alternative would be come up with some sort of integrated tagging plugin, but I'm not sure it's worth the bother. I've been using mutagen, so I don't know whether the available perl modules are even up to the task. In the end I use a small perl lib I wrote which uses MP3:Tag. It can set all the tags I need, including APICs etc. That's good to know. I've done a little bit of poking around in the perl MP4 tagging libs, and it seems like most of the bits one would need are there as well, but I haven't put them through their paces. Not quite as tidy as Mutagen, but we are living in a perl world here. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Broken list threads
For anyone who is using Gmail, a button appears when reading emails from a mailing list to automatically create a filter for the mailing list. This has worked successfully for me so far. Jeremy ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
