• Get involved.
    We want your input!
    Apply for Membership and join the conversations about everything related to broadcasting.

    After we receive your registration, a moderator will review it. After your registration is approved, you will be permitted to post.
    If you use a disposable or false email address, your registration will be rejected.

    After your membership is approved, please take a minute to tell us a little bit about yourself.
    https://www.radiodiscussions.com/forums/introduce-yourself.1088/

    Thanks in advance and have fun!
    RadioDiscussions Administrators

OMT Media Touch ongoing problems - lag between audio cuts

B

bossbill

It's been a while since we've asked for help with a recurring problem. This is an OMT-built system, configured by them.

A stopset always has several audio cuts. OMT had told us before that we had a problem with lag between cuts because we were making the file length exact, and they advised that the lag problem would go away if we made the file slightly long and then used EOM to make the audio exact. Well folks, this doesn't solve the lag problem. Each cut is EOM'd per OMT specs, exact length. OMT also told us to do refrag often. So we're doing defrag every night, and on a stopset we sometimes get a lag of a half second between cuts, which of course is additive, and can result in coming out of a stopset as much as 3 seconds late. This doesn't work with a network rejoin.

Any tips? Anyone? Anyone?
 
Bill,

A couple quick questions:

What does your countdown timer do at the end of the sound file when playing? Does it keep counting after the audio ends? Does the timer stop counting when the audio stops, or does it 'gray' out and after the pause the next file starts playing?

The reason I ask is I've had the exact same problem, but in my case the clock went to gray right at the audio ending yet continued counting for one or two seconds. In my case after troubleshooting (and some dumb luck), I managed to isolate the problem to a bad sound card. I replaced the existing Audioscience sound card with a good ol' Soundblaster card, balanced up the audio using a Henry Matchbox and had not seen the problem after.
 
Do you use this in a server configuration? Is the player playing it from another computer?

Simian and Wave Station have lag time as well if your on air is pulling from another computer as a server. A defrag helped. Ultimately we were able to change properties in file sharing which helped. Having files ON the play computer would resolve the problem.

Had an OMT that used the internet to transfer files. This was a train wreck because local news can't take that long to transfer to the local folder. Record and expect it to play on station 2 in 5 minutes? No.
 
Bill-

We're running iMediatouch 3.1.9, the latest version. We're configured so that the on-air machine holds the database and is networked with production, logger, and a traffic machine (for the log tools program). We do NOT use a separate server. We have no such problem. Are you running a server?

Typically, we cut a spot and then use the "time" feature to stretch or compress. Our spots typically look like this after doing so:

:30 spot: EOM: :30.000, Stop: :30.003, Length: :30.003
:60 spot: EOM: 1.00.000, Stop: :1.00.005, Length: 1.00.005

The length rarely is exactly :30 or :60. As I said, there is absolutely no lag.

If you're running a server, have you tried creating a test category on the LOCAL on-air machine, bypassing the server. You could run your stopsets off that category, and if the lag disappears, this would certainly point to a networking problem.

If you're using a server, I'm wondering about your switch. Is it a cheaper SOHO switch? We're using a HP Procurve 1400 (unmanaged) and it's throughput and latency are excellent. On some of our office computers using the cheaper switches, we've had problems with "lag."
 
ChiefEngineer:
We've setup the computers to defrag every morning, the server computer defrags twice a day, and we still have issues with frequently replaced files (hourly news that's saved as cut 1000, 1001, 1002, etc) fragmenting often.



ChiefOperator:
There is an OMT-supplied server, but each system is configured to copy the audio to it's own backup drive. We have one system that isn't on the air yet, i can try the local vs. networked category idea. but if that's the case how do you copy the categories from machine to machine?
Our network is isolated with static IP's and custom host files (previously discussed).

HowardMBurgers

From home I don't recall what it does when it plays but i do seem to remember it counting to it's entirety even if the tone moves the system to the next cut, I'll check this later today. - If it was a bad card I would question how we managed to get three bad Delta's in OMT-built systems though.




I had setup each machine with the record function connected to the 3/4 input side of the Delta 44's. I disabled this 'feature' since no one used it and I'm watching for the latency issue.

Does anyone use this feature?

do most people have more than one Delta 44 card?

What version of DirectX do most people run on their OMT machines?
 
Also a question on Delayed cue;

Does anyone use this? We had a problem with spots needing to get replaced the day they were scheduled to air - plus we re-use some cut number per day, and would run into the issue of 'open for read' (error -9988 if i remember correctly) to resolve this we added our COM category to the delayed cue list per OMT.

Does delayed cue == delayed audio for anyone?
 
I should have been clearer. I was trying to determine whether the stopset carts are actually stored on each individual on-air machine and aired from the particular machine or whether the stopsets are stored on a server and then streamed across the network. The local vs. network idea was merely a test to isolate the problem.

We use only one Delta 44 in our logger and one in our production machine. I believe that we do NOT use the feature.
 
Hmmmm. We do NOT use delayed cue. I *believe* that iMediatouch buffers the audio so that the carts start immediately. I wonder whether delayed cue prevents it from buffering.....
 
Doesn't matter which automation system it is - if you're playing from a server, you're gonna get lag. Simple as that.

Plus in 2010 it's downright foolish to run automation without primary playback from a local hard drive. If your vendor says "we don't support that" then its time to get a system that does.
 
We're not playing from the server. Everything copies from the server to the individual on-air sytem. We have 4 stations on the system. All production first hits the server then propagates to the individual drives. Playback is from the local drive.
 
What else are you running on MT On Air? Ideally you should only have MT On Air, Defrag, and possibly Second Copy and Datacast on your on-air machine. It might be worth watching Windows Process Explorer to see what, if anything, is happening on the machine so you can eliminate the possibility that something is hogging resources.
 
I'll defer to Aberdeenman on this, but I don't believe we're running anything else on the On-Air machine. We have separate production machines, separate Logger for pre-records.

And since we're using satellite feeds and a Broadcast Tools switcher, the On-air machine isn't being asked to do much, but play stopsets and liners.

Reference an earlier post, all our spots are EOM'd at exact time, with the file itself slightly longer, so typical might look like:

Cart EOM Stop End
TEST 00:30.00 00:31.05 00:31.05

The problem became more severe when we changed providers and there is a five-minute stopset certain hours, making for more audio cuts. Each cut is EOM'd exactly, but when we get 6 or 7 cuts together, with the perfect EOMs, we end up with the lag, and because of the number of cuts, the individual lag results in a stopset running from a second long to as much as thre seconds long. Defragging has reduced the problem, but still running long sometimes. The network return liner fires right when it is supposed to. If we leave the liner channel up, we then overlap with the end of the spot, if we don't, then we sometimes clip the beginning of the liner. It had been suggested we place the liner in the stopset, but not all stopsets are filled, so that creates a problem for traffic. We were spoiled by our old system, which would cue and hold the return liner until the stopset finished, plus the old system didn't have a lag problem, so worst case with an occasional spot slightly long, would be a slight delay with return liner, which then produced a slight overlap with the next song, which wasn't bad.
 
Boy, I really have no idea, especially since all audio is played from the local drive of the machine. Our iMediatouch system plays from the local drive as well, as I mentioned in my earlier post. There is absolutely no lag; in fact, our stopsets are tight.

I'm wondering about that "delayed cue" mentioned earlier. As I understand it, the event moves into the "cue" and buffers slightly so that the event fires immediately. I know that once our events are cued, they cannot be opened from the production side (we do not use delayed cue) I'm wondering whether your delayed cue setting prevents the events from buffering and thus creates a short lag.

I'm out of ideas..
 
Try running the on-air machine without its network connection (disable it in Windows, don't just pull the plug as that can cause all sorts of grief).

If the problem goes away then investigate what's configured on the machine that's accessing the network.

If not, then there's likely something running on the on air machine that's taking away power from the on air app.
 
Bill-

I just looked at our machine again and narrowed something down. Under On-Air configurations, Play Timing, take a look at the "Level Detect EOM" selection. We use it for our music category only. But there is an option to "use for all categories." If this box is accidentally checked, the EOMs for all categories (including COM) will be disabled and the system will look at the audio level, not EOMs. This would certainly run your stopsets long.
 
no we don't use the level detect EOM, and yes the only thing these machines run is the on-air program and defrag (I use contig but same same).

The reason we use delayed cue on that category is specific to features/news that we've had problems with in the past.

How do other stations handle media that gets recorded daily such as features and news items? If the feature is saved too late, or the spot load too light, the cut ends up getting queued up too soon. When I deal with this from the news room I go in to logtools and move my own news cut then save/import and move it back.
 
David:

Download Windows Process Explorer (procexp.exe) and see if you have anything that is running in the background on the machine.

Your only two process and memory hogs should be the database and on air. Process Explorer will tell you right away if there's something else hogging resources and what it is.
 
procexp shows the machine running between 94 and 98% idle. no unaccounted for processes or memory hogs.
 
aberdeenman said:
How do other stations handle media that gets recorded daily such as features and news items? If the feature is saved too late, or the spot load too light, the cut ends up getting queued up too soon. When I deal with this from the news room I go in to logtools and move my own news cut then save/import and move it back.
Click to expand...
MediaTouch tip: You can recue a memoed spot by dragging it to a new position on the right side of the log (where the cut number and time details are). So you might move your news down after the news sponsorship. Wait a couple seconds; it should re-cue. Then you can repeat the same procedure to move it back where it belongs. Much faster than using Log Tools.

As far as the spot playback problem, do you have multiple cuts in the "PTA" list when a break sets up? MediaTouch changes the "Start" button to say "PTA x Start" when the audio is ready to play, where x is a number ranging from 1 to 3 (in my set up, I believe this is configurable).

You should be able to figure out whether the problem is based on the end of a spot (ignoring EOM, for instance) or the beginning (fetching audio) by running the system in "Live" mode (Auto Off). Have a real person start each spot in the break and note any lag from the time he presses start to the time audio begins to play. If there is no such lag, it would seem to be an ignoring EOM problem. If there is lag, then we at least know that the delay is in grabbing the audio to play.
 
David:

At least you have the stray process issue eliminated as a possibility.

Anytime I have had dead or delayed audio its been because of a PTA failure. Is reporter in log tools showing On Air reporting any errors?
 
Status
This thread has been closed due to inactivity. You can create a new thread to discuss this topic.


Back
Top Bottom