Hi Rob, What is causing this script to run so slowly, the rewriting of the audio file to modify the header? Or the DB calls? I do this across multiple software I have written, the latest was WebGopher which needed to attach Cart and SS32 and other headers optionally after retrieving syndicated programming from the net, modifying the format, and placing it. Speed of the header modification simply is a factor of the buffer size available in the system to read and write back out the audio data. We deal with some pretty large files, upwards of 500M. An average modification time is about .1 seconds, on a 500MB file it might by 5 seconds though. Only place I ever had an issue was on a Windows Server 2003 machine which did run slow as molasses, but changes in the buffering fixed that too. Those settings can be a bit tricky to optimize and behave in unexpected ways but are critical to the script chugging along quickly.
If the setup is continually scanning and modifying the audio files to stay sync'd with a database I can certainly understand that being quite processor intensive. This is something that rightfully simply needs to be done any time the file is touched by Rivendell, not as an outside program rechecking everything on the off chance something has changed, or when a change has been detected even. Done that way, the extra processing time to add 1000 bytes of data or so would be completely undetectable and insignificant. I think in this case the thought wasn't necessarily to continually write and update the whole library, but rather to make a utility that would do add a snapshot of the current database entry to a selected subset of audio files that could then be copied and reintegrated into another Rivendell installation bu reversing the process and reading the data back out. Still a bit time consuming, but probably much less so than trying to move the files and recreate the data manually or with the other script. Best TC -----Original Message----- From: Rob Landry [mailto:41001...@interpring.com] Sent: Monday, June 30, 2014 9:38 AM To: Thomas Churchill Cc: 'Hoggins!'; rivendell-dev@lists.rivendellaudio.org Subject: Re: [RDD] Rivendell exchange file format On Fri, 27 Jun 2014, Thomas Churchill wrote: > Rivendell would have to save the metadata in a chunk in the audio file > itself in the var/snd directory. Right now that info appears to be > only included in the database. I can understand the attraction of attaching metadata to each audio file, providing a degree if redundancy in case the MySQL database gets trashed. However, there really ought to be only one authoritative copy of the metadata. If it's in the audio files, that would make a program like rdlibrary God-awful slow. I have written a script for a client of mine who uses AudioVault; my script reads a daily log, retrieves all the relevant information about each event from its audio file, and displays it all on a Web page, coloring each event green if it's present and up-to-date and red if it's missing or outdated. I should have named that script "largo", because it's as slow as a snail. Oh, and I should add that AudioVault encodes all its audio file metadata twice: once in a CART chunk, and a second time in an AV10 chunk. Only the AV10 data is authoritative. Rob _______________________________________________ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
