Bug#535957: clive: --format switch doesn't work anymore
A follow-up. Fixed/changed in 2.2.3: * add --upgrade-config: convert 2.0/2.1 config to 2.2+ format * allow use of --format=(mp4|hd|hq|3gp) with youtube git://repo.or.cz/clive.git -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535957: clive: --format switch doesn't work anymore
Remaining issues: * -f best gives regular flv for Fuchs * cannot reproduce with the test link (sent by email) * fmt_map contains fmt18 and -f best gives fmt18 (for me) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535957: clive: --format switch doesn't work anymore
-=| Toni Gundogdu, Sun, Jul 19, 2009 at 01:54:58PM +0300 |=- A follow-up. Fixed/changed in 2.2.3: * add --upgrade-config: convert 2.0/2.1 config to 2.2+ format * allow use of --format=(mp4|hd|hq|3gp) with youtube git://repo.or.cz/clive.git I have mailed Toni and he said 2.2.3 will be released next week. -- dam signature.asc Description: Digital signature
Bug#535957: clive: --format switch doesn't work anymore
Gerfried Fuchs:
I don't know what mailer you use - but can you please
tell it to not break threads?
Can you hear me now? ;)
And like noticed yesterday, why did I receive a mono flv
even with -f best when -f fmt18 gave me a mp4 with stereo sound?
If -f best gives you the regular flv and -f fmt18 gives
you mp4 *for the same video* then that's a bug and needs
to be looked into. I haven't received any reports regarding
-f best so I've assumed it works. I rely primarely on bug
reports.
inconvenient for the users to have dig up what formats there
might be now and there. That's why they use a tool like this
and not extract the download URL themself from the html source,
mind you.
No one is expecting the users to go over the html. I'm not even
sure why you would think that was necessary.
Bear with me.
Manual page:
fmt22 .. mp4(1280x720) (HD)
fmt35 .. flv (640x380) (HQ)
fmt18 .. mp4 (480x360)
flv .. fmt34 (320x180)
fmt17 .. 3gp (176x144)
The reason I chose to parse the fmt_map string in the html
instead of iterating over the IDs and connecting to the
server to try if it returns an error should be apparent.
e.g.:
...
if ( $config-{format} eq best ) {
$fmt = $1
if $$content =~ /fmt_map: (.*?)\//;
} ...
# $fmt should contain any of the above IDs (e.g. fmt22)
As far as I can tell, the fmt_map string varies for at
least some videos. Possibly older. I'm only guessing.
What seems certain (until now if you found a bug) is that
the first one in it indicates the best format.
The rest of the fmt_map remains mystery to me, although
it seems to indicate at least some of the available formats.
So why doesn't mp4 strive for the best mp4 format available?
You mean why -f mp4 didn't do that previously?
I, for one, don't care to download the HD (fmt22) which is
typically much larger file to download due to the higher
resolution than the regular fmt18. They may use the same
audio quality, though.
So you are saying that one needs to remember even which fmt
number is used for which service?
mp4 - fmt18 hardly means steep learning curve. The fmtxx
IDs are for youtube only. If you look at the manual page,
you'll see that there aren't that many IDs. Youtube and
Dailymotion are the only ones with several IDs.
users - I am worried about all the regressions the completely
reworked config and commandline handling brings with it when
they upgrade at one point from lenny to squeeze. To some degree
this reminds me of the xmms - xmms2 changes, and I guess you
know how much of a userbase and goodwill it did cost them.
I can't say that I know of the xmms changes but I get what you
are saying. I really have no intention (or interest) to revamp
clive anymore, and while that may not help with these changes
you have written about, but it may be something worth keeping
in mind which ever way you guys decide to go.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535957: clive: --format switch doesn't work anymore
Hi! I don't know what mailer you use - but can you please tell it to not break threads? It neither sets In-Reply-To nor References which makes it look a bit imature and breaks threading in proper mail clients ... Thanks. :) * Toni Gundogdu lega...@gmail.com [2009-07-14 00:53:09 CEST]: Gerfried Fuchs wrote: this ever changing thing with every single release and being incompatible with every version before is [...] That's 15 releases and about six months between 2.0.0 and 2.1.14 alone. So what you are saying in the above quote is exaggeration. Multiple (at least noticed two, and it isn't important enough for me to dig around for further) intentional brekages involving users to have to dig around within six months isn't much of a exaggeration, IMNSHO. When I did try -f fmt18 it worked, also with -f best -- both did get me mp4. Why doesn't -f mp4 give me mp4 anymore? I'm assuming we are talking about the Youtube support. Google still supports mp4. As does youtube, but I guess you mean a different thing when you say mp4. We now use the same IDs that Youtube does instead of the aliases that were usually only missleading. In the long run this is best for everyone, only the users but whoever may try to fix the support. You think users having to dig up what fmt18 and fmt22 might find it less confusing? Sorry, but I can't disagree stronger here ... For example, fmt18 and fmt22 are both mp4 formats, so we would see reports from some users saying that mp4 download no longer works Why doesn't clive want to help the users then and obscure it even further with fmt22, fmt18 and whatsnot? And like noticed yesterday, why did I receive a mono flv even with -f best when -f fmt18 gave me a mp4 with stereo sound? Sorry, that's not what I call best and it's highly inconvenient for the users to have dig up what formats there might be now and there. That's why they use a tool like this and not extract the download URL themself from the html source, mind you. -- when it fact it did, but resulted in lower quality of mp4 when they used -f mp4 while hoping to get the HD (fmt22) version of the video. The use of mp4_hd only seemed to confuse some users even further. So why doesn't mp4 strive for the best mp4 format available? Fulfilling expectations is not what you are striving for it seems? * Youtube uses fmtxx for its formats And it's a complexity that doesn't need to hit the users. IMHO. * this makes debugging and finding a fix easier For debugging people usually offer debug switches. * this means less confusion about the formats among users devs I won't buy that, sorry. * no need to read source code to figure out the aliases Need to read source code what fmt might be needed this day? This goes also along with the rest of the program design. We have been using host specific format IDs for Dailymotion for about year now. So you are saying that one needs to remember even which fmt number is used for which service? Wow, that's really userfriendly indeed. With -f best you may have downloaded either one (fmt18 or fmt22 in this case), depending on which was listed as first (best) in the HTML. Received a flv, see above. :/ Sorry, I can just encourage everyone to switch to a different product than clive Well, that seems rather harsh. I guess you gotta do what you gotta do. If you consider expressing ones feelings is harsh I feel sorry for you - but that's what this whole issues that popped up in the last months made me consider. I should probably point out that clive is not a product. If it was, I wouldn't be writing these emails. This sentence doesn't make any sence to me, but I guess you have your reason to write that. Ryan Niebur wrote: I agree fully [with Fuchs], having a wrapper script around clive that I've had to update multiple times. at this point (despite me working on keeping the clive package up to date...) Well, whatever the case, whatever you decide to do, thanks for keeping up and making clive2 available for Debian users. I'm just not too convinced that it's really a service to Debian users - I am worried about all the regressions the completely reworked config and commandline handling brings with it when they upgrade at one point from lenny to squeeze. To some degree this reminds me of the xmms - xmms2 changes, and I guess you know how much of a userbase and goodwill it did cost them. Just like a xmms2 developer told me today: #v+ Eclipser as I said, I don't care about users Eclipser users are crap #v- So long, Rhonda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535957: clive: --format switch doesn't work anymore
* Toni Gundogdu lega...@gmail.com [2009-07-11 13:09:15 CEST]: [...] clive doesn't even be able anymore to download mp4 files from youtube. [...] You did not give any examples so I'm assuming you did not try -f fmt18. No, I didn't, I used the old options and also the documented parts in the example config file. When I did try -f fmt18 it worked, also with -f best -- both did get me mp4. Why doesn't -f mp4 give me mp4 anymore? Note that fmt18 (mp4) may not always be available for reasons unknown to me. All of the hosts and the formats that they support are covered in the FORMATS section of the manual page. It's one thing that they aren't always available, it's a completely different thing that -f mp4 simply stopped working where -f best or -f fmt18 still does get me mp4 files. Sorry, I can just encourage everyone to switch to a different product than clive -- this ever changing thing with every single release and being incompatible with every version before is just getting annoying. I also recommend reading the change log from time to time. For every single update? Sorry, that's extremely inconvenient and I'd even say ridiculous. No single other tool or package does change that much with every single version, I spot regressions in every update that happened in the last months, which just is too much for a sensible tool. Sorry, extremely disappointed to the end. Rhonda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535957: clive: --format switch doesn't work anymore
Hi! On Mon, Jul 13, 2009 at 11:32:42AM +0200, Gerfried Fuchs wrote: I also recommend reading the change log from time to time. For every single update? Sorry, that's extremely inconvenient and I'd even say ridiculous. No single other tool or package does change that much with every single version, I spot regressions in every update that happened in the last months, which just is too much for a sensible tool. I agree fully, having a wrapper script around clive that I've had to update multiple times. at this point (despite me working on keeping the clive package up to date...), I have stopped upgrading clive on all of machines because porting and testing my script on every update is too much of a PITA. Cheers, Ryan -- _ Ryan Niebur ryanrya...@gmail.com signature.asc Description: Digital signature
Bug#535957: clive: --format switch doesn't work anymore
Gerfried Fuchs wrote: this ever changing thing with every single release and being incompatible with every version before is [...] For the sake of this thread, lets take a look at the timeline of those changes you wrote about: * 2.0.0 - late 2008 (first beta in September 2008) - config format change - config path change * 2.1.14 - late May 2009 - initial --format ID changes for Youtube (excl. mp4) * 2.2.0 - mid June 2009 - config format change - config path change - --format=mp4 - fmt18 (Youtube) That's 15 releases and about six months between 2.0.0 and 2.1.14 alone. So what you are saying in the above quote is exaggeration. For what it's worth, there are no further plans to change anything as heavy handedly anymore. Only maintenance updates if anything breaks, and additional support for new hosts if anyone happens to whip up patches. 2.2 ironed out everything that still had to go or get rewritten. I think the changelog may have also implied that. When I did try -f fmt18 it worked, also with -f best -- both did get me mp4. Why doesn't -f mp4 give me mp4 anymore? I'm assuming we are talking about the Youtube support. Google still supports mp4. We now use the same IDs that Youtube does instead of the aliases that were usually only missleading. In the long run this is best for everyone, only the users but whoever may try to fix the support. For example, fmt18 and fmt22 are both mp4 formats, so we would see reports from some users saying that mp4 download no longer works -- when it fact it did, but resulted in lower quality of mp4 when they used -f mp4 while hoping to get the HD (fmt22) version of the video. The use of mp4_hd only seemed to confuse some users even further. * Youtube uses fmtxx for its formats * this makes debugging and finding a fix easier * this means less confusion about the formats among users devs * no need to read source code to figure out the aliases * cleaner code This goes also along with the rest of the program design. We have been using host specific format IDs for Dailymotion for about year now. With -f best you may have downloaded either one (fmt18 or fmt22 in this case), depending on which was listed as first (best) in the HTML. Sorry, I can just encourage everyone to switch to a different product than clive Well, that seems rather harsh. I guess you gotta do what you gotta do. I should probably point out that clive is not a product. If it was, I wouldn't be writing these emails. Ryan Niebur wrote: I agree fully [with Fuchs], having a wrapper script around clive that I've had to update multiple times. at this point (despite me working on keeping the clive package up to date...) Well, whatever the case, whatever you decide to do, thanks for keeping up and making clive2 available for Debian users. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535957: clive: --format switch doesn't work anymore
[...] clive doesn't even be able anymore to download mp4 files from youtube. [...] You did not give any examples so I'm assuming you did not try -f fmt18. Note that fmt18 (mp4) may not always be available for reasons unknown to me. All of the hosts and the formats that they support are covered in the FORMATS section of the manual page. I also recommend reading the change log from time to time. It's not just a list of technical changes in the program as one might assume: http://code.google.com/p/clive/wiki/Changes Or here (development): http://repo.or.cz/w/clive.git?a=blob_plain;f=CHANGES;hb=HEAD -- * I am not maintaining this package * I am not subscribed to this mailing list -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535957: clive: --format switch doesn't work anymore
Package: clive Version: 2.2.0-1 Severity: important Hi! Since the last update and the switch to a new config file format and all the troubles that it brings clive doesn't even be able anymore to download mp4 files from youtube. No matter what I put into ~/.cliverc, no matter what commandline option I try, I always end up with an .flv file. Given that the sound track in .flv is mono in contrary to the .mp4 this is an extremely disappoiting regression which would be great to get fixed. Thanks in advance, Rhonda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
