ColdFusion

what fix did you use for the "flash upgrade required" problem? this looks like something related to CSS, do you have any related plugins? The pandora player put itself in a div with id "TunerContainer" or in an iframe named "tunerFrame", i'm not sure which is the one that causes it to get displayed there. &lt;div id="TunerContainer"&gt; &lt;iframe src="http://www.pandora.com/?cmd=mini" scrolling=no id="tunerFrame" name="tunerFrame"&gt;&lt;/iframe&gt; &lt;script type="text/javascript" src="js/pandora.js"&gt;&lt;/script&gt; &lt;/div&gt; try putting a few line breaks ("<br>") in the pandoraGrabber.html file, just before the code shown above, let me know if this workaround works.

it's not really a 'pandora's-jar' sourceforge project, more like "pandoar's jar CF branch". www.sourceforge.net/projects/pandoras-jar I'll upload a homepage when I have time to do so.

Hey there mrmath, first of all - thanks for helping us all improve pandora. I too have created a split since I saw no one was really working on keeping stuff up to date on the 7.4.0 branch and no source-repository was available. second, bugs... adding features is great but what about solving bugs? does your version still have the "&" bug that's in 7.4.0? now for the rest of the comments... I think we should work together instead of in parallel, my version is available on sourceforge, you are more than welcome to join the project and contribute. there are even a few open bugs. here are my comments about your version, this is just my opinion and thoughts - nothing more: My version supports arbitrary file name format with custom string %a/%a-%t and so on, I think that's much better. by preventing files from being re-ripped you indeed avoid ripping files that you have deleted - but what if a file was ripped but under the wrong name? you're stuck with it. In addition - take a look at my mp3md5 (both local and online modes) feature - this is my way of fixing (though not completely) the wrongfully named tracks problems I think a good solution would be to fetch all the info needed and combine it into the already saved files. actually there is even an open bug on SF that says we should never overwrite a file with a smaller file if they have the same first few kilobytes (as that would mean it is the same song but it got stuck before it finished downloading), I guess that when fixing that I could apply the solution presented here. great feature. great! again, it is much better to enable the user to enter a generic string for the file path. the default genre sound nice, though from my experience pandora does not really play a single genre no matter how hard you try to make it stick to one type of music. my solutions was just to enable the user to use the entire station name as the genre, I also offered a "mapping file" to map a station name to a certain genre - but that was unpopular. I think this will be popular. I really don't mind having a look at the ads, they're quite easy to ignore and the service it totally worth it. p.s. If you'd like me to store your version on my server for everyone to download - let me know.

if you mean 'how far', I haven't even started re-writing it. should take me less than an hour, but I've got loads of stuff to do at work. sorry.

What's that? OCR is optical character recognition. as the station info is obviously visible on screen - you can grab it using weak-AI techniques such as OCR. that would be extremely dependent on the pandora UI not changing, plus a hell to debug. (not to mention write).

I love it! so simple yet so productive! perhaps I'll implement it as "reload after x songs OR y minutes without a grab" be sure to find this feature in PJ_CF8!

Schmoe, something is extremely wrong with your setup. for starters - why are you running both noscript and the greasemonkey solutions? secondly - if you're using one of the above mentioned solutions - why are you still opening two tabs?

I'm sure I don't know a way :-) There might be one that I am not aware of. apart from OCR-ing it out. which would be quite easy though quite a bit out of scope.

could you provide more info about that software "Replay Music". Notice that there are a lot of mp3-tagging solutions out there, little apps that complete the id3 tag based on the artist/title. but for that the artist/title must be correct to begin with. there are also apps that find out which song is which by analyzing what it sounds like (See http://musicbrainz.org/). I'm working in the direction of being able to fetch info from pandora's backstage website. as the mp3 we're working with are all from there - that should be a good source for most of the info. I'll also be working on improving cddb integration soon.

SporkRocker, take a look at you default.properties file, specifically the lines: #File/directory name format # %a - artist; %b - album; %t - title; %s - station # NOTICE: if no album / station data they will be replaced with "UNKNOWN" # if nothing specified here, defaulting to: "%s/%a/%b/%a-%t" # spaces are fine, don't add .mp3, use forward slashes don't start with / #filename.format=%a/%a-%t uncomment the last line (remove the "#"). and set it's value to whatever you want. from what you say, I guess you'd prefer this: filename.format=%a/%b/%a-%t Cheers, CF

What are you trying to say? what's the problem with the comment? That's not strange at all. pandora requests a flash upgrade only if it's not running in the topmost frame. Which "waiting" messages? there are two that I can think of, one relates to the file not being fully downloaded, the other to not having pandora's jar loaded before pandora.com. I suggest using one of the following solutions: 1) the greasemonkey solution. 2) the new solution by Razor512. (http://www.hak5.org/forums/viewtopic.php?p=55620#55620) 3) the noscript solution. the "open in a new tab" seems to stop working after a refresh, or after a few songs, I don't know, haven't tried it much.

dude, read everything before you ask... 1) 2) the "same-md5" error means that the file you are trying to grab is the same as the last file grabbed. it prevents saving the same file under two names. in this case - the second click is the correct name... too bad. don't click within the first 15 seconds!!! the timestamp on the "current playing" song should help you know if it's the right time... if the song you want to grab just started and the timestamp is more than 2 minutes... obviously this is not the time to click "grab"... refresh the page, and when you see the new song name - hit the grab link. notice. do not "refresh" the result page (the one saying the file was grabbed) - it will cause another grab attempt.

Horray, CF7 is out. not what I expected to have in this release, but some neat features nonetheless. same download page on sourceforge... http://sourceforge.net/project/showfiles.php?group_id=184854 If you don't need any of the features here - there's no real reason to upgrade from CF6. Changelog for PJ_CF7 (released 13-Jan-2007) 1) bug fixes none 2) new features 2.1) added an option called "remote grab", when it is on - pandora's jar must be in cruise control. the grabbing done in cruise control will not actually cause the file to be ripped, but rather just let the server know that a new song is playing (with artist / title info). then, the server can be accessed using the address http://localhost:port/monitor this will display a short text page with info about the song currently playing (if the cruise control sent the info already (default: 15 seconds into the song)): a) the amount of time that passed since the info currently displayed has been sent (to verify sanity of the data before hitting "grab") b) a link to initiate a grab (just like hitting "grab this song"). c) the name of the last grabbed song + the time passed since it was grabbed. (again for 'sanity QA' purposes) In this mode - a click on "Grab this track" in firefox will not grab the song, a second click on the same song will grab it. (notice that clicking the link in the monitoring console will init a rip anyway. no two clicks needed there. if you click when a song just started playing - it will be saved with the info of the old song!) Main use case: this feature has been requested by a user that is listening on a wireless headset and would like to be able to grab songs remotely using his PDA (equipped with WIFI). if you have a wireless headset but no PDA you can also access the page remotely using you cellular phone and WAP / GPRS / EDGE (etc). [usefull as a remote for grabbing while listening in bed and so on...] 3) chages in configuration default.properties - enabled setting port number, specify "server.port=" , good if you want to run pj simply by double clicking the jar file (if they're mapped to be run by java on your pc), but you don't want to us port 80. - added "mp3.maxsize", defaults to 25MB, comment out in order to disable limit. will not save any grabbed file if it is larger than specified size. (this was done because someone was experiencing a bug where files >80MB were grabbed!) 25MB limit seems more than reasonable. - changed mp3md5 config format to support three options "off , local, online" off = don't try to verify anything (md5 comparison to last file grabbed is still made) local = create and use a local text file for collecting md5->songinfo votes online = connect to an online mp3md5 database (hence opt-in to collaborate with others on the voting) 4) changes in log minor changes, for new features. Waiting for feature requests, but reports, suggestions, solutions and developers who wish to contribute from their time to the project

That's it! I'm uploading version CF7 code and jar to sourceforge right now. debugged the hell out of the new remote monitor feature. seems to work correctly. let me know how it works for you! Cheers on the flash solution thingie! Here's how this works: added an option called "remote grab", when it is on - pandora's jar must be in cruise control. the grabbing done in cruise control will not actually cause the file to be ripped, but rather just let the server know that a new song is playing (with artist / title info). then, the server can be accessed using the address http://localhost:port/monitor this will display a short text page with info about the song currently playing (if the cruise control sent the info already (default: 15 seconds into the song)): a) the amount of time that passed since the info currently displayed has been sent (to verify sanity of the data before hitting "grab") b) a link to initiate a grab (just like hitting "grab this song"). c) the name of the last grabbed song + the time passed since it was grabbed. (again for 'sanity QA' purposes) In this mode - a click on "Grab this track" in firefox will not grab the song, a second click on the same song will grab it. (notice that clicking the link in the monitoring console will init a rip anyway. no two clicks needed there. if you click when a song just started playing - it will be saved with the info of the old song!) Main use case: this feature has been requested by a user that is listening on a wireless headset and would like to be able to grab songs remotely using his PDA (equipped with WIFI). if you have a wireless headset but no PDA you can also access the page remotely using you cellular phone and WAP / GPRS / EDGE (etc). [usefull as a remote for grabbing while listening in bed and so on...]

sounds great, are there no unexpected side effects?

info grabbing has not been improved in any way in CF7. have you got any suggestions?

dude, I'm sorry, but there's no way that 7.4.0 worked with flash 9. unless you were running some kind of beta version of 9 which is not publicly available or you had 8 in the cache and firefox somehow used that or something like that. use flashswitcher to overcome the flash version problem. use greasemonkey (or noscript) to overcome pandora asking you to upgrade your flash. this is how it works for all of us since they started requiring flash 9. While I'm extremely interested in figuring out how/why flash 9 did work for you - I don't think it's possible until you are able to reproduce that situation. most likely you are confused. good luck. I'm here if you have any more questions.

what did you do on the PPC to get: (?) I assume your PPC is named NARUTO. (after the ninja?) anyway - I'm proud to say that in CF7 which is about to be released there is an option do initiate the grabbing remotely. to do so - uncomment the config entry: "remotemonitoronly.mode=true" (or add this line to your config file - if you're not using the config that came with the release) I'm not so proud of the code thats involved in this, as it is very messy. I'll clean it up sometime (hopefully soon). more info will be available with the release.

Alas! (I think this is something that will be hard to overcome.) my best suggestion to you is to listen to different stations, change once every few hours. after a few days - just set pandora to 0-volume and listen to the files in your archive with shuffle on - it will be the same as quickmix. if you want to quickmix only some of the stations - load their m3u files into your player and shuffle on that... pandora will be downloading new files into your archive, while you'll get the same experience as listening to quickmix of the selected stations - with the abitlity to hit back and next as many times as you'd like. what do you think?

most likely never. not based on 7.4.0 anyway. flash-9 no longer saves mp3 files in the temp directory. using flash8 with flashswitcher and greasemonkey is not bad at all. and whenever you need 9 - switch to 9 and then back to 8.

Do you mean "they will all grab the same song"? or do they actually play the same song? Even if you can get multiple pandoras running - pj will mix up the temp files. so don't do that! most of the files grabbed will be named incorrectly. play one station at a time, or use multiple computers. a clever trick might be to run multiple firefox instances using different temp directories. if anyone manages to do that - and check if the flash is also fooled into using the other temp dir - this could be a good opportunity for some experiments in parallel ripping! NOTICE: even if you rip in parallel (even on different computers) only one station name will be detected - and it will be the same on both machines! for parallel ripping - either listen to the same station on all instances or use different pandora accounts! [/b]

birra, stop quoting everything! leave just the relevant part (if anything). As I've said - there's no way for me to know which station the quick mix is currently playing. I suggest that if station info is that important to you - quickmix on your own... listen to a different station every time - for a few hours each. notice that when you switch stations - pandora's jar is most likely to grab the first file wrongfully. this is a known bug - it is caused because the song that was supposed to be next on your previous station is already waiting in the temp folder - hence pandora's jar detects it as the one that's currently playing. as we didn't get correct station info until now - I didn't have any way of working around it... but I suppose some sort of solution will be integrated into CF7 which is on it's way. If you have any suggestions of how to know which station quickmix is using - I'll be thrilled!

Well, greasemonkey injects the code into the downloaded page, there's no way of mimicking that behavior without using greasemonkey. you could use NoScript instead - but that has lots of other disadvantages.

ver 9 of what? flash? I can't understand a word, could you rephrase that please?

Sounds like the kind of thing I'd like to write! I'm on it, Let me know what you've tried so far - or at least what ideas you've had. just a small question - why not use cruise control? cheers.