• 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

iMediaTouch technical help - pregnant pauses

We had a similar problem with one iteration of Simian when we replaced a pci trigger card with a usb device, but they cured that in the later versions. My best guess at the time was that the USB trigger device and the USB dongle were fighting each other. End result was that the machine paused for a fraction after playing each element of the stop set--ending up in breaks running long.

We have had problems in the past with the ABC classic rock net--but they just liked to run their windows too short. Since switched to Dial Global and those problems ended, for the most part. However, most systems take a fraction of time to react to the netques, so the net should give a slight pause before hitting the fill material in optional breaks to avoid a "burp" of sound before the system switches. We also try to keep spot lengths consistent, using time stretch when necessary; remember some systems show spot lengths as :30 or :60 when they are actually :30.25 (for example). Adds up in a 4 minute stopset.

Simian, when used with the audio science sound cards, uses that audio card's virtual mixer to provide smooth segues (either a fixed overlap or an overlap set when you load that audio file).

Of course, Simian lacks the touch-screen feature of the iMediatouch systems, which is much more useful for live-assist formats. And it will not work over a network, although you can load spots and logs into it through a network.
 
Only time I've ever seen an automation system behave like this, was with an old Prophet CFS system running on Novell. We had several NIC cards "chattering" that were causing severe network congestion. The on-air servers would lose track of time then play catch up on the next segue between two events.

It was quite the aha moment when we finally figured it out.
 
VoiceOfReason said:
Also, if anything adverse happens on the physical LAN, the localhost communications are held off while Windows checks the physical LAN state, which can also cause loose playback.

This tip alone is a VALUABLE piece of advice. Essentially Windows Networking SHUTS DOWN - local connections included - if there's any network disruption like what VOR describes. That's why most automation systems don't use a playback system that is network dependent - even if it's a local drive accessed through UNC or localhost configurations.

It might be worth double-checking RJ45 connections and network switches to see if that isn't part of the problem.
 
I first have to admit that I'm weighing on here a little late on this conversation but I'm the local engineer that setup the network and helped with the install. I'm extensively versed in the Audiovault system (and kicking myself now for not pitching it a little harder when we purchased the current solution).

To answer a few reccuring question:
  • The audio plays locally, you can unplug the 'clients' without loss of audio.
  • The network is isolated through the third octect, with a dual-lan machine acting as a gateway using VNC to remotely control neccesary computers.
  • I've run packet sniffing software on the network and see no excessive abuse, about-time is about the chattiest
  • The file server is running Windows Server 2003, with 2gb of RAM (to OMT specs - in fact they built and set it up)
  • The clients are identical HP's running XP with 2gb of RAM (same as above, built and setup by OMT)
  • I understand that 3-4 gig of RAM would be greeeeaaat for any machine (with the correct settings for XP and server 2003 to actually ADDRESS the ram) but the software only "requires" 1 gb of RAM, and these PC's do not run AV software, or any other application. - the Fileserver for example does nothing else besides a backup application that runs on Sundays

I would also note that the Audiovault software had it's own version of growing pains, and those AV100 cards were NOT fun at times, but overall I'd go back to *.ini file configurations and proprietary cards (which are not neccesary any longer with Vault btw) if I had the choice.
 
audiophile. said:
Doesn't make a lot of sense to me.

Why not just put return liner at end of stopset, same as spot?

Another problem this creates is that the sat channel is turned off at this time, so after the return liner (as prt of the stopset) it would dump to sat.

- sorry if this has been brought up already - I'm on page two, catching up.....
 
VoiceOfReason said:
Keep in mind that the actual playback on iMediaTouch is handled by a separate background program called pta.exe (Play To Air). The user interface communicates with the PTA via the network stack using a couple of ports through localhost (127.0.0.1).

It's my understanding that if no EOM is set, the UI waits for pta.exe to signal back "I'm done playing the cut" before starting the next. If ANY EOM is set, the UI relies on internal progress timers to determine if it's reached the EOM.

In Windows, the network stack seems to get lower priority in processor time than other things. So, if anything "distracts" Windows, network communication can hesitate. This in turn can cause the UI and PTA to not communicate for a few MS. I've seen it happen.

Also, if anything adverse happens on the physical LAN, the localhost communications are held off while Windows checks the physical LAN state, which can also cause loose playback.

PTA and OnAir will retry communicating with each other a few times. After a number of retries, OnAir will log a "PTA Failure" and try to restart pta.exe. If you get to PTA failures, you have something wrong either with networking, or with Windows "thinking" really hard about something and ignoring the network while it does.

If you want, PM me your contact info. I'm usually very buried, but will help if I can.

This issue makes sense, however the frequency makes me wonder, for example if pta or network connections were my issue would I see the lag all the time, anytime, or specifically between each commercial we play? We see no lag in liners, sweepers, or any other local audio) when live we see no lag between song-sweeper-song elements.
 
I don't know if you've tried this however might be worth a shot; network congestion sounds like it could be the issue.

Have you tried locking down your NIC to 100/full as opposed to AUTO? I had a couple machines from factory (Prophet) come to me in AUTO mode and the audio playback behaved exactly like you describe. Once I locked the NIC down it performed like a dream.

Just something to toss out there.

C-
 
chris560 said:
Have you tried locking down your NIC to 100/full as opposed to AUTO? I had a couple machines from factory (Prophet) come to me in AUTO mode and the audio playback behaved exactly like you describe. Once I locked the NIC down it performed like a dream.

Done from the factory, I agree this can become an issue with networked PC's, but the setting is already in place in this case. I'm about to reccomend a 1gb network upgrade just to rule out NIC issue, but in the end it's in the loopback because the audio is local. (loopback TTL is 128 on a ping 127.0.0.1 cmd)
 
aberdeenman said:
  • The network is isolated through the third octect, with a dual-lan machine acting as a gateway using VNC to remotely control neccesary computers.

This makes it sound like you are running concurrent networks on the same switches. That could add latency, since the switch will have either multiple, or much more complex rounting tables.

How about if you completely isolate the iMedia Touch network from the rest of the network? Put a router in to allow the iMedia Touch network to access the rest of the network, and the outside world.
 
SirRoxalot said:
This makes it sound like you are running concurrent networks on the same switches. That could add latency, since the switch will have either multiple, or much more complex rounting tables.

How about if you completely isolate the iMedia Touch network from the rest of the network? Put a router in to allow the iMedia Touch network to access the rest of the network, and the outside world.

The OMT computers are all mapped to the 192.168.10.x network, with a single dedicated router, there is a dual-lan computer that also can see the rest of the building on the 192.168.1.x network, I can unplug that machine, but I see no cross-traffic through wireshark, and none of the OMT machines can see anything outside of their own network - the switch itself cannot see the 192.168.1.x network and there is no router on the 192.168.10.x network.

Ultimately we do not want these machines to see the outside networks anyway, so a router is an option we did not want. The single computer with dual-lan provides the gateway between the two networks.
 
aberdeenman said:
audiophile. said:
Doesn't make a lot of sense to me.

Why not just put return liner at end of stopset, same as spot?

Another problem this creates is that the sat channel is turned off at this time, so after the return liner (as prt of the stopset) it would dump to sat.

- sorry if this has been brought up already - I'm on page two, catching up.....

This shouldn't be a problem, if you can set an "outro" on return liner to bring back network...
 
audiophile. said:
This shouldn't be a problem, if you can set an "outro" on return liner to bring back network...
Logically this would work, however when going from local audio to Satellite the EOM's are ignored, the EOM's on OMT only work when transitioning from local audio to local audio.


Update on the system:

I'm in the process of adding one second to every commercial/PSA and adding the EOM tone at the 30 or 60 mark respectively, I'll let you know if this solves the issue.

I've recently heard other iterations of our affiliate-feed along the west coast, and what I heard was that they were using the return closure to hard-stop the commercials, this leads to "call 1-800-7.. out-sweeper and then satellite". While I'm sure that's also an option, I'm not yet willing to cut off paid ads. I also should say I don't know what automation they were using, but that abrupt stop sounded sub-par.
 
aberdeenman said:
audiophile. said:
This shouldn't be a problem, if you can set an "outro" on return liner to bring back network...
Logically this would work, however when going from local audio to Satellite the EOM's are ignored, the EOM's on OMT only work when transitioning from local audio to local audio.

That's a major bummer, because you could have fixed this issue by now if it did that...
 
Well kind of, but I wouldn't have called it 'fixed' a :60 should play in 60 seconds, and three :60's should play in 180 seconds, there's shouldn't be work-arounds in place because the computer needs to think about the square root of 42 in between every peice of audio.
Adding the return liner to the end of the stopset would only 'fix' when the stations goes from stopset to liner to music - sometimes they go from stopset to satellite-promo to liner to music.
 
I've recently heard other iterations of our affiliate-feed along the west coast, and what I heard was that they were using the return closure to hard-stop the commercials, this leads to "call 1-800-7.. out-sweeper and then satellite". While I'm sure that's also an option, I'm not yet willing to cut off paid ads. I also should say I don't know what automation they were using, but that abrupt stop sounded sub-par.


Sounds similiar to the Ingraham feed. The network stopset always runs 1 or 2 seconds late and often cuts off...
 
An update to our issue:
After manually adding 1 second to the end of all COM and PSA's, and adding the EOM tone accordingly, the stopset seems a little tighter however a new problem arises with this 'solution'.

If I reply on an EOM tone to END my stopset, and the automation won't honor the EOM when moving from local audio to satellite audio, I get the tail of whatever the last spot was in it's entirety, regardless of the reccommended tones. (so instead of an aggregated second making my stopset long, I save it up for the end of the stopset)

To resolve the COM-to-SWEEP issue I've set it up to keep the sweeper channel open when playing local stopsets, this does however leave open the potential to train-wreck the end of a stopset if I have one :61 second COM.

This also doesn't address when the network goes from COM-to-Network liner, which can still jump abruptly from the end of my stopset into the network.

I also have less hair today.

Ohhh how I miss If/Then.......
 
These short pauses can be a defrag issue. Are you running a defrag program on your server? We run diskeeper on our server and it keeps things up to speed most of the time.
We have not found a cure for longer delays that cause PTA no response errors or PTA:requested recue errors, in our Media touch system.
 
When I was playing around with ANother Brand of Automation some years back, we found out that the sound card drivers had a considerable effect on how the thing worked, and that it worked best with the driver the developer wa susing when he finalized the software.
I realize it's a time consuming drag, but when you are completely bald, try going to one of the sites with old drivers for your sound card, or finding the original CDs for it (good luck!) and trying each in its turn. This was the salvation using a Digiram product, the softwarew got heartburn from the newer drivers.
 
Dave has followed iMediaTouch advice on defragging. As far as sound cards, this is the system iMediaTouch provided as "shovel-ready" for prime time, and was set up, installed, configured, by iMediaTouch on location.
 
Sounds like OMT should send you another box, in the event the one they installed is bad.

Has anyone checked out the LAN interface on the box? We once had issues that were resolved by dropping a new network card into the system.
 
Status
This thread has been closed due to inactivity. You can create a new thread to discuss this topic.


Back
Top Bottom