Same thing here, I check my schedule today and all the shows starting next Sunday are totally empty of conent!

I already said this a few times...

update: managed to clear this problem it by clearing all browser cache/history, and it may be a slightly different issue if content is actually disappearing (with the (!) marker appearing) which I did once have happen but thankfully have not had it for a while. It might be worth splitting off these two posts in case anyone else gets this as it is equally alarming to see especially in the more pressurised environment of a bigger community radio station

Unfortunately today I got the same thing happen as Divay - content removed (but show time still there)
all the shows were repeated and linked with no end date. Also there was one overlapped show but unfortunately I didn't manage to get that screenshot.

I had it happen before - it seems to be after a certain time (as if something is hardcoded into the system to assume that shows cancel after n weeks irrespective of end date). Unfortunately I am not sure exactly when this happened...



what is even more strange is the show times are all still correct, its just the content which has disappeared.

I will try and recreate the calendar in the same way as Davey, and it as I happen to be working from home today I can switch to my home studio and ZaraRadio playout, but this needs to be dealt with if this project is to go beyond hobby stations and those community broadcasters with full studio setups and staff to operate them, and such things as independent silence detector equipment/emergency playout.

I am a former broadcast engineer who worked for a large company which supplied many broadcasters worldwide and their high priced systems often had serious bugs and/or customer feature requests were not implemented or in such ways that caused other issues. The company nearly went bust, downsized several times and what remained of it ended up being bought out by a competitor (even then both companies are a shadow of their former selves). My paid day job is now in telecoms and IT for healthcare (which has to be far more robust and resilient) as its safety critical - but the budgets are available for extra kit for backup systems.

To be fair airtime is one of the best radio playout software available,
better than many commercial systems (which also have very lean dev teans) -  there simply isn't as much money in the radio
industry as even 10 years ago - even mainstream stations (commercial
and public service) are increasingly using part time staff /
freelancers who have other day jobs, unpaid interns, and many broadcast engineers are
expected to divide their time between multiple stations rather than
being assigned full time to one station.

{However were this to happen to a small broadcast station (with both Band II FM TX and net streaming)dependent on income from advertising and they did not have an independent ad playout system (perhaps even using analogue switching of audio sources) they could really be in trouble.

Plus  in most countries the Communications Ministry really do not like it if a broadcast station is transmitting dead air or has repeated gaps in playout. This sort of issue (without suitable backup plans) could result in such a station being fined (as well as any civil claims for missed advert playout) and even losing its TX license.

How to make a program come back - at least on here.
Add a track to your (now) seemingly empty show
Delete that new track.
Hey presto - the old show is back.
I have posted this trick several times before.
This bug was reported for 2.50 and 2.43 - Its still here in 2.51

Quote Denise: "The easiest way to rid the messed up schedule is to do as @Divay did and clear everything from the cc_show table."

This is NOT easy and for me is several days work! If it worked that would be fine but it did not and made no difference at all. I did this on 2.50 and had to do it again in 2.51 again - all for nothing. A few days later, shows started losing content. I sent in a copy of the database showing the bug in the days of 2.50. This really needs sorting out.

Firstly this issue seem to happen here only on repeating linked show. It seems to 'lose' the content on a show  'update' ESPECIALLY when you change its time of start or finish. The clue must be when subsequent 'add and delete' of a track happens - the old show reappears. So what happens when the show gets deleted and the show content redisplayed - because that works? Is this a different save/display routine than a normal save/update?

When a show's content had unexpectedly 'disappeared' and looks empty - then it is this missing show's content that reappears - in its entireity.

I have explained this to you several times before over 4 months - including in the bug tracker. And to Albert S. I am not making this up.

NOTE. When a show's content has unexpectedly disappeared - if you cancel the show at this point and reschedule a show in the same time slot - both shows can play at the same time.

All this has been reported before.

The shows do not disappear. The show's contents do. And I can make the show's contents re-appear. I hope this is now clear.

I have also remade the table (thankfully as it is a small EDM station which is still in "experimental" stage) it wasn't as much work, and If I get further issues will try the other solution (I did notice one instance where content disappeared and then reappeared)..

But this whole issue would really cause a problem at our community radio station if I used Airtime there.

I will try and keep a sharp lookout for "what is ahead", as what I found before was that everything was fine for a few weeks then suddenly the (!) started appearing on the calendar.

In the meantime I would strongly suggest to any radio stations using Airtime for playout who could suffer serious financial and/or reputation damage from dead air, they set up a silence detector on the monitoring output and some way of triggering an emergency audio source, even if it means using legacy analogue equipment or even building custom switching systems. thankfully at least in Europe, many advertisers/investors in community stations and the Communications Ministry staff are sympathetic and understanding and accept that things can go wrong. The BBC radio service n London regularly has playout errors, and 27 seconds of dead air is allowed before its treated as an emergency!

This weekend I filled my calendar for the month of April. All shows have been created with "repeats" and "link". I filled them with Smart Blocks/Webstreams. Then I unchecked "link" on the shows filled with Smart Blocks. Shows with webstream content are still linked.

And today I noticed... The shows filled with smart blocks became empty, starts from april 14 :(
Is there logs I can post to help you?

Same here. It seems to me its a monday problem.

just had the same thing happen as well (wasn't able to check the stream on Monday but it may have happened then

if anyone suggests which log files/database I should share I am willing to do so so we can track this down...

this happened again on Monday (it happened the Monday before, but I thought I had found a workaround by making all the linked shows less than 1 month end date).

I have ended up temporarily reverting to using Centovacast on my main shoutcast stream simply to ensure there is some output, as I suspect the database is hosed and reinstalling airtime (presumably I would get the 2.5.2 update?) is probably the best option.

In any case there is another issue; shows that overrun and should have been faded are not; causing the timing of the playout of each show to drift ; cumulatively this could be 6 - 7 or more minutes wrong (even after taking into account lag due to encoders etc).

If someone can respond fairly quickly (I've got a day job during UK office hours so tend to deal with my online station in the evenings) and confirm whether there is any advantage in going to 2.5.2 (if its even released, or 2.5.3 is the latest) I can grab any log files or the old database/any other useful data; it is not clear whether these issues have has actually been logged or addressed.

I have looked on the bug tracker but not found any info - nor details of any definite workaround (linked shows and the ability to fade overrunning shows (I pad out underruns with jingles and random (and often bizzare) short items) was the main reason I started using Airtime in the first place....

Alex

Ok, I reported this here : http://dev.sourcefabric.org/browse/CC-5854
You can vote if you are affected with this bug.

Alex if they're playlists, can you try adding one track to an empty show see what happens? Sometimes the whole show will come back if you do that.

I am glad somebody else said that. I was not believed.
Sometimes it seems if you Update the show without changes - it works too.

I have tried that but the content does not appear. Also updating shows seems to add to the duplicate shows (also with blank content) its as if some indexes in the database are wrong.

Incidentally the show content is a long MP3 (1 to 2 hours) preceeded by 1-3 short jingles between 2 and 15 seconds (+ other filler material if there is still an underrun) - as Airtime usually fades the overrun items and starts the next ones on time; but there are also occasions where it doesn't do so and the only solution is rebooting the server (having activated something else to feed the stream).

It is possible that a lot of Airtime users who play a format where the music is individual tracks (rather than a DJ mix) are also using standard analogue mixing consoles and/or simply living with the bugs or not being affected by them; as another playout package I evaluated (Windows based) also choked on long audio files after a while, but everyone who used it with 3-5 minute MP3 single tracks did not have these problems.

I put a bug report in for the time drift as well

http://dev.sourcefabric.org/browse/CC-5857

I hope I have done that correctly as I am not an expert coder (I can dabble with a bit).

John; is your station format similar to mine, with heavy use of pre-recorded shows (as I have a paying day job and run the station as a hobby?) That said, even most licensed community stations use long pre-records for their overnight playout

Re. Time drift.
I don't get that but I have cron job updating the station's time server every few hours.

NTP daemon on my server (is hosted in NL) gets a pulse per second sync directly from VSL  (Dutch Metrology Institute) - it happened automatically when I selected them as the NTP sync source; maybe the datacentre is nearby or the Dutch are just very proud of their atomic clock. That means the server time is as accurate as you can get and beyond that required for broadcasting services where about a second tolerance is accepted, the BBC normally uses NPL MSF time but can use GPS or DCF77 (Germany) as a fallback.

I was experimenting last night with Liquidsoap itself on a German server for transcoding streams for mobile listeners; managed to actually get it to work (albeit not AAC+, but thats not a disaster as I think 96k AAC is minimum acceptable for low bandwidth listening - I doubt the rural mobile "broadband" will stretch to 48k anyway, but it works better in the less affluent areas of town).

I am now considering just using a combination of this for weekdays and perhaps going back to Zararadio and the analogue equipment / playout for weekends, as I wanted to do live shows anyway; at least until this is sorted out.

If it is not possible or there are simply not the resources at Sourcefabric to fix this I might as well just re-image the Dutch server, and use this for liquidsoap as the TX schedule is repeated anyway (the idea being to make it easy for those in Asia and America to listen at their local timezone) so I wouldn't need to write as many playlists, and for my purposes the pretty front end is "nice to have" but not really essential.

A further discovery I made is liquidsoap has its own bugs and quirks, which impact on the reliability of Airtime (perhaps the drift is caused by the fade in/out times not being sent correctly to liquidsoap?)

I am old enough to remember when computers did not have GUIs and out of curiosity often read ancient tech reports about 1980s era computerised playout systems, so am willing to sacrifice the GUI for reliability; at the same time if the data on this kaput system is any use for bug fixing I can preserve it if someone responds with what I need to gather.

Is that Bart from Contact-Dance België? I remember moving my transmission of Rob's mixes so it did not clash with the one on your station...

I checked this, the clock on the server (and the one airtime uses) has always been correct; liquidsoap does have not just one separate clock but a different one for every stream, but uses the main server clock for timing purposes as does airtime. Being a former "old skool" broadcast engineer who works in telecoms as a day job and who has older friends who used to set up the type of clocks used in the BBC and at Hilversum, I am quite fussy about getting the correct time for any critical system.

The "drift" is approximately the amount that would occur were some of the overrunning shows not faded correctly at the out point (which could happen if wrong data is being sent to liquidsoap).

That is exactly what I did (I left the server timezone as CE(S)T as that is where the server is located), and also did all the server preparation tasks. the NTP daemon output is below.

More important is the wider bug with shows becoming empty. As previously mentioned I left the Airtime running (whilst sending my music from a different method) to see what might happen. I also tried putting in the dummy content to see if things reappeared.

They didn't, either I was left with a show containing just the extra content, or a blank one (if I deleted the dummy content); or a random show got added 1 hour ahead of another, overlapped with existing shows (could this be a confusion between UTC and local time, which in Europe changes for summer?)

I've just looked today (Tuesday) and a show I had left dummy content in is now empty, since Monday.


 ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ntp.nmi.nl      .PPS.            1 u  566 1024  377    3.348    0.055   0.680
+arethusa.tweake 193.79.237.14    2 u  838 1024  377    1.153    0.149   0.796
+bandersnatch.ro 85.12.29.43      3 u  384 1024  377    1.361   -0.295   0.552
+fw.ams.nl.alexs 82.197.221.30    4 u   36 1024  377    2.376   -0.020   0.965
+europium.canoni 193.79.237.14    2 u  991 1024  377   10.681   -0.847   0.477

I hadn't looked at the actual content lengths as they seem to be more or less correct when they are imported; up to a second drift is tolerated by most European broadcasters (as they often use a neighbouring countrys time standard as a backup to their own). What is stranger is that everything is spot on for a few days, even a week or more; then the "drift" starts, followed by stuff disappearing.

If I have to set the server to UTC I could try that but would like to still use the very accurate Dutch time server as a reference (do you mean actual UTC which remains constant the year round, or UK civil time which will also vary in Spring and Autumn? The Airtime manual itself actually refers to setting up a server to UK civil time, and implies that the lot should work in any country's time zone (although the user time zones can also be changed).

Also the show which had the dummy content but also became empty had been deleted and rescheduled after the UK time change. I also made the end date a month afterwards to see if I could get round the bug reported as occuring with shows having no end date or more than 2 months.

The NTP daemon on this server is running, and it is keeping good time.

The "drift" was more likely shows that are overrun not being faded when they should be; I don't have the time or maths skills to work out what the cumulative error per day/week would work out as - it was because Airtime is supposed to do that automatically (and the user interface gives the indication that this is the case). 

That was why originally switched to it from the Centovacast panel you have to manually edit each audio file and unless its all done to the exact second that will drift, Centovacast does not fade audio that is playing.

If the "Station time" is not what is being used for scheduling and any other system clocks may be involved this should documented or it is going to cause people all sorts of confusion. I am only keeping this current install running as there could be some clues in its database (the audio content is still there, the shows are there, its the calendar which is empty); and am unsure what to do with it; whether to reimage the server and re-install airtime or just use liquidsoap and "roll my own" with the scheduling bit.

I don't know why this bug is still here, it happens every time I schedule new shows! It is very annoying...
Does a developer has tried to reproduce? It is very easy by following the steps :
https://dev.sourcefabric.org/browse/CC-5854

HI, we operate a new Radio in Austrai and we today had this "empty show" problem and we had no sound sent to the icecast servers.

Running 2.5.1-3 on Debian 7.2.

Looks like I had the same as John had. Itcould have been following renaming an repeated show with no ending date.

We already had that one time, and deleted things from the database. This time it was curious:

- Editing show content shows empty show
- "Show Show content" still showed the titles

Browsing postgress the show instance 518 was still there and cc_shedule had the titles with instance 518 and correct date/time starts/ends in the db.

Does somebody have a clue how one can fix this in the database with sql commands if it happens?

There must be a difference in the select clause when reading the DB for listing titles in edit mode and for showing the title in content list only.

Appreziate your help. On Air with no sound is very bad and we had some very disappointed users today.