Even though you have carefully prepared all your MP3 files with the correct ID3 tags, I've found that I sometimes have to modify or add new tags. Airtime keeps the files in a couple of places: its import directory (usually /srv/airtime/imported/) and its watch folder. The Airtime admin web interface does allow you to modify the tags it knows about (the ones in the list in Library list), but this is very tedious when you have 40 or more entries to change. Here's an example of how easily to change the ID3 tags so Airtime knows about the changes (as verifiable by refreshing the Library tab and then searching for the affected artist in the list).
This is a two-step process to make sure the mp3 files and the database get the same information. This example shows how to change the genre for an artist named Porous (the genre is currently 'Rock').
1. Use your favorite ID3 tag editor (EasyTAG is a simple Gnome application, or eyeD3 for people who use the Terminal) to select the artist Porous and change the genre to 'Hip Hop'. In EasyTAG, click the artist name in the top left panel, select all of the songs in the right pane list, type 'hip hop' in the genre field (in the ID3 Tag - Common tab), and click the small, square button to the right of the genre text. The log at the bottom of the page displays the number of files changed.
2. Use your favorite postgreSQL admin tool (I like phppgadmin) to modify the airtime database. Run the SQL command: UPDATE cc_files SET genre='hip hop' WHERE artist_name='Porous'. The number of affected entries should match the number of files changed in (1).
Uploaded a track the other day with the track title set but no artist. Instead of broadcasting the title with a blank artist field, it simply didn't broadcast either. Updating the ID3 tag live seemed to fix the file, but it took a full stream stop/restart to force the thing to update. Much weird. Much unfortunate.
Hi Roger, could you file a bug in JIRA for the issue above please? I had never tested uploading files with blank fields, perhaps the playout engine is choking on a null value. Cheers! Daniel
Airtime ONLY reads in the metatags from the file at first import. It uses ones in the database after that.
Hmmm, John - my experience does not correlate with your statement that Airtime only reads the meta tags from the file at the first import. I tested this by only making tag changes to the database (cc_files table) for the artist_name or track_title fields, restarted Ubuntu and voilà, my changes were gone!
Apparently, Airtime DOES read the tags from the files and updates the database every time it starts up. I've gone
back to my original, two-step method in which I change the tags in the files and then in the database.
My airtime has been up for 5 months. So I guess thats why I see it differently. I also set the real ID3 tags using my RSS Importer before airtime ever sees it.
Post edited by John Chewter at 2014-07-07 03:27:01
Hi Wade, please file the above behaviour as a bug, because any local changes to metadata should be preserved after a reboot. If the media monitor is re-analysing a large library after a reboot, this might also be causing unnecessary CPU load. Cheers! Daniel
I've done more investigating and the behavior is even odder than I suspected. When I use easyTAG to examine and modify the ID3 tags in the imported library the database is updated almost instantaneously. This implies that the media monitor is constantly analyzing the files in the import library and notices changes made to individual files very quickly. My guess is that the media monitor pays attention to modification dates and re-analyzes a file if the modification date changes.
Post edited by Wade Eilrich at 2014-07-07 12:24:11
Hi Wade, I believe that media monitor uses inotify to monitor for file changes. Updating the database on a file change is no bad thing if the Airtime library is being acted on by an external program, such as a legacy broadcast system integrated with Airtime. This is likely to be an issue for watched folders outside of the main Airtime storage directory.
Could you run a test for me please? What happens if you modify an item of title or artist metadata using the Airtime admin interface, then reboot the server? Do you still see the modified value in the Library view, or does it revert to the original metadata from the file?
It could be that by modifying the cc_files table directly, you are missing a step in which the file is recorded as having been updated, and so on reboot media monitor is trying to fix this metadata 'error'. That's just a guess, but it sounds plausible to me.
Daniel - I modified a title tag in the Airtime admin interface and then rebooted the server. The title change persisted across the reboot. I've not had any problems with my watched folders and I use them extensively for linked, repeated shows.
Examining the cc_files table I see several timestamp fields. In particular, the mtime and utime fields look like the have to do with the last time the file was touched (mtime) and the original importation date (utime).
I'm guessing that Airtime, when one uses the admin interface to modify ID3 tags, updates the information in the file (using cc_files->filepath to get the file location). Then the media monitor notices the change, re-analyses the file, writes the tags to cc_file, and updates cc_files->utime.
By modifying cc_files directly (and not modifying the associated file) the utime field is still technically correct because the file has not changed. How does Airtime know that I have modified the database, but not the file? I'm glad it works this way because the thought that the files are out of sync with the database is disturbing. Two solutions present themselves to me: (1) if Airtime notices a discrepancy between the tags in the database compared to what is in the file it re-analyse the file and updates the database (this appears to be what is happening), or (2) Airtime notices the discrepancy and modifies the file to correspond to the database.
I think it would be a bad idea to force choice (2) by setting utime to the current time (without actually modifying the file) when I change a tag in cc_files. I'm not sure this would even work because I would have created two discrepancies between the file and the corresponding entry in the database. On reboot, the mechanism Airtime uses to look for database discrepancies would use (1) to fix the problem.
Now that I think I understand the basics of how Airtime synchronizes and validates cc_files, making changes to the ID3 tags is simple: just modify the file and media monitor will update the database for me. The documentation, should this be acceptable, needs to change so people understand that both the imported and watched Airtime folders behave similarly: simply adding or changing a file in either location will immediately update the database and the change will appear in the admin interface.
Monit shows a very low CPU load even when I batch modify dozens of files and only uses 2% of the available memory (approximately 42500 KB).
Post edited by Wade Eilrich at 2014-07-08 12:28:30
By the way, monit and media-monitor are two different programs. Monit is a general-purpose utility for checking that services are running (http://mmonit.com/monit/) where as media-monitor is the Python program which watches Airtime storage for new or changed files. Confusingly, we use both!
Hi Daniel, in the online manual, the chapter: Media Folders contains this information:
"Edits to your stored and watched media files are noticed by Airtime. If you edit any file known to the database and change its duration, Airtime will automatically adjust the duration of playlists, smart blocks and shows that the file is included in."
This is correct, but not complete and may be a bit misleading because it implies that one needs to change the duration of a file to allow Airtime to notice a change. A possible third sentence may help users:
'If you edit any file known to the database and change its ID3 tags, Airtime will automatically update the database with the new information. This may invalidate existing playlists or smart blocks that the file is in. For example, if you use 'genre' as a search criteria to create a playlist and then edit the 'genre' ID3 tag for a file, the file no longer matches the original search criteria. The playlist would have an entry for the original file because it was created before you modified the ID3 tag.
I use the Monit Service Manager (available on the server's Apache port 2812) to keep an eye on the status of my Airtime server. Conveniently, it watches the airtime-playout, airtime-media-manager, and airtime-liquidsoap serivces. It provides me with general statistics including uptime, CPU total, and memory total as well as allowing me to easily start/stop/restart each of these services.
I have been monitoring this thread closely. What I dont gets is...... If I have an mp3 called latest.mp3 and I overwrite it with another latest.mp3. (eg the news) in a repeating show, this show instances do not change in length. In fact it doesnt seem to notice at all for any pre-existing shows. I use this trick every day.
John, that definitely runs contrary to what the documentation says with the possible exception that you are not changing the duration of a file known to Airtime. Instead, you are replacing that file with one that has the same name. I'm not sure if the difference is salient. I'll bet that even though the names are the same, the ID3 tags are different. Perhaps that is enough so that Airtime does not recognize the new file as the same as the old one.
Yes the tags are different. The filename is the same. In the library, it shows the new and correct duration, BUT in any pre-existing shows (show_instances table) the keep the old duration and does not change. There are a few of us exploiting this including me and Krypton Radio as will be found elsewhere in the forum. We wish it would use the new duration and shuffle the show times to accomodate it. But is does not. Alas.
I'm going to have to try some further experiments with pre-existing, linked shows. In another forum, you recommended that I create a "dummy" file that takes up the entire show - I did that and the linked shows now play correctly. However, before doing that any linked shows that had content longer than the original were just cut short (at the original time). Worse, had it happened, would be shows that are shorter and created dead air. That did not happen because I modified the ls_script.liq to play a selection of random songs if nothing is playing. Getting that to work correctly, with proper fade-in/fade-out was a trick in itself.
What I will try, early next week, will be to re-create my original linked show in which the replacement files are deliberately longer than the original. Then I'll see how I can change the times in the database to get it to work. Several tables are very interesting: show_instances (file_id, time_filled, modified_instance), show_days (start_time, duration, repeat_type, next_pop_date), and show_instances (starts, ends, time_filled, last_scheduled, and modified_instance). In particular, the show_instances field time_filled looks promising.
This is because the show instance timing are frozen at show add-content time. The timings in this table are NOT updated by media monitor. If it was - we would have no problem.
I looked at modifying the instances timing and concluded that it was way too time consuming and complicated to write code to retime all for the subsequent show track timings, if AT 2.5.2 is going to change these tables very shortly. So It should be very simple to change the main mp3 timings IF there are no tracks following it in the show. Else you will get multi concurrent mp3 playouts
Post edited by John Chewter at 2014-07-10 11:22:00
I'm hoping that I can establish the duration of the show block using show_instances starts and ends (end - starts = show block duration). Then I can use the time_filled to give me the amount of time left in that show block (show block duration - time_filled). I can calculate the additional time needed by comparing cc_files length of the original file to the length of the replacement file. If the additional time needed is greater than is available in the show, that is an error and I need to redo the show. Otherwise, I can use additional time needed to update show_instances time_filled.
For the first few of these, I'll do the modifications by hand to make sure I've got all the steps. Then I'll write a script to do the work. I know the developers are refactoring the database. If the problem is fixed, great - otherwise I'll have to work out another script and wait for the next release. I can't use Airtime yet in a production environment because of the onerous US copyright policies so this is a development exercise for me. Once Airtime makes it easy enough for me to produce shows that follow the US copyright policies, then I'll have to take a hard look at production level issues.
I've created my show blocks that use linked content to have ONLY one file associated with them. This obviates the concern about getting "multi concurrent mp3 playouts". I know it is not optimal, but with the existing playout problems (shows not starting on time, synchronizing with live feeds, multi concurrent playlist playouts, etc.) that is my working solution du jour.