have a look at the files that download but don't cart and see what is in the mp3 tags.
I have had issues with files which to all intents and purposes are OK but had obscure characters in tag files. mp3 players are not fussy but rdimport is! Somewhere I have a tag clean up script that sets everything to null except the Title and Artist. Solved the problem for me. Check the sample rate too. RD can be a bit fussy at low or odd sample rates. resample fixed the problem on one source which would not play through on two different systems. [RD & Jasler] wget pulls the file in resample using lame output file with a different name to the dropbox One of our providers has an origination system which outputs files as .MP3 with filenames including spaces that RDCATCH would not handle. [and we tried everything] wget allows us to download, rename, and the file works! In summary there is a lot of vestigial junk in mp3 files which are definitely not all created equal. Programme originators don't understand or care. Fortunately you can automate the clean up process. I look at each source on a case by case basis rather than have a jiffy fix all script because every time you resample audio you lose a little. Sometimes tags and renaming are all that is necessary. Cowboy will remember when all we had to do was switch RIAA/CCIR/LP/FLAT! regards Robert Jeffares On Sat, 2014-03-15 at 11:54 -0500, Brandon Sossamon wrote: > I might add that the Status states Unknown Audio Format yet they're > all mp3 including the one that downloaded successfully. > ---brandon > > > On Sat, Mar 15, 2014 at 11:45 AM, Brandon Sossamon > <[email protected]> wrote: > > Perhaps this will garner a response... > > I went back into RDCatch this morning and noticed that 1 of today's > > events downloaded successfully and placed the audio in the correct > > destination. The other event scheduled for this morning is > > highlighted pink. If I right click on it and select "edit cue > > markers", it gives me the following error: > > > > Unable to download peak data, error was: "RDXport service returned an > > error". > > > > I wouldn't be surprised if this isn't operator error. I'm just > > comparing all the events and they seem to be set up identically and > > proper according to the ops manual and wiki. Can someone lend some > > advice as to what else I should be checking? Many thanks! > > > > ---Brandon > > > > > > On Thu, Mar 13, 2014 at 8:54 PM, Brandon Sossamon > > <[email protected]> wrote: > >> I'm currently running my machine in test before putting it on the air > >> chain so pardon the string of questions that may follow in the coming > >> week. Just trying to learn all of this and get it on the air by > >> April. > >> > >> I created a daily download event in RDCatch for a news report I > >> subscribe to. It's posted as an mp3 in an open website (no username > >> or password). The event in RDCatch turns green for 2 seconds at the > >> download time but puts no audio in the destination cut and displays no > >> error. I've double checked my set up against the ops manual and the > >> wiki article and everything seems to be done correctly. Does this > >> issue ring any bells? > >> > >> Furthermore, there is another mp3 file on the same site that I > >> download daily. The address is this format: > >> > >> http://<name>.<domainname>.com/<filename>%20thursday%203-13.mp3 > >> > >> In order to get this into RDCatch, do I need to use the wildcard %% to > >> recognize the "%20" and "%203-13"? In other words, should the address > >> be entered into RDCatch as: > >> > >> http://<name>.<domainname>.com/<filename>%%20thursday%%203-13.mp3 > >> > >> -- brandon sossamon > > > _______________________________________________ Rivendell-dev mailing list [email protected] http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
