iMediaTouch technical help - pregnant pauses

[bossbill]

I'm looking to users of current iMediaTouch automation for help on a couple of technical issues. I'm not out to trash the company or the system, but trying to solve a problem. And yes, we have been trying to solve it through their tech support, but so far the solution seems to have eluded them and us.

Specifically, we are having an issue with runtimes of stopsets. When we schedule several audio files into a stopset, the system creates pauses between the audio files, which then makes the stopsets run long. The pauses are perhaps from 0.2 seconds to 0.6 seconds each, and the resultant runtime of the stopset is sometimes 1-2 seconds long. This of course creates an issue during a satellite break, when the return liner fires before the stopset is done playing.

Troubleshooting demonstrates that the audio files are all exactly proper length, and air-checks show these mysterious pauses between the audio files. We have determined through extensive head-scratching that the satellite return liners are firing at the proper times, but because the stopset is running too long due to the pauses between spots, the return liner is clipped.

The system was provided by the company, and was set up and configured by them.

Again, I'm not looking to bash a company or system, or make comparions between other systems that may or may not have the same issue. I am trying to solve a problem which has plagued this particular system on both of the stations we so far have implemented it on.

Any help will be greatly appreciated.

 

[ChiefEngineer]

You have some infromation but missed an important one. Server? Number of connections?

You DID mention all the elements are correct length. So a 4 min break with 2 60's and 4 30's ends up 4:03?

Audio Delay sometimes equals drive access time. If you have delays make sure you are not puling from an overtaxed or incorrectly setup server. The remote computer could be calling for it and it just keeps trying to play but won't "play" until it "buffers" for lack of a better explanation. Are both computers same operating system, same workgroup, allowed to share files? An upgrade of microsoft awhile back related to IP6 caused some issues at our place. The Vista backward upgraded to XP for better operation would not allow the former better XP non Vista to pull files. Changed sharing file parameters. Automatic download and someone installed in at 4 in the morning...

How many systems are sharing the server?

A setup here had two stations A and B (remotely connected) sharing a server in town B.

Other issue is commands in the stopset. Are you turning things on or off in bvetween elements?

How much ram? At least 2 g or 4 g?

What network?

 

[DudeFan]

Also, have you set the EOM points in Production? IMediatouch will not hit next element until EOF if there is no EOM present.

 

[bossbill]

Thank you for your input and questions.

The server and the local computers were provided as a system by iMediaTouch. They say everything is configured properly. The system was based on having 4 station on-air units and 4 production units sharing the server, but only two have been implemented. The problem existed with the first station we set up, which was actually configured on-site by a iMediaTouch-provided technician.

The local computers are XP Pro, HPs, 1 gig RAM, provided pre-loaded by iMediaTouch. The server, again provided by iMediaTouch (OMT) uses Server 2003.

The On-Air local computers do nothing else, no extraneous software, no outside world access except for the server, etc. Production is done entirely on totally-separate computers.

There are no commands in the stopsets.

In your example, 2 60s and 4 30s may end up as 4:00 or 4:01 or 4:02. It is inconsistent. The basic problem is that the stopsets run long because of the gaps in audio, and thus the return liner is clipped when it fires at the right time.

OMT tells us they don't have this problem with any other systems in the field.

I'm hoping maybe this can ring a bell with somebody that has an iMediaTouch system.

 

[bossbill]

The EOMs on spots are at the end of the audio file (is that EOF?). They've told us that the EOM gets set at the end, unless we move it. The media library info shows, for example, a file of 1:00.0 with an EOM at 1:00.0.

 

[DudeFan]

Just wanted to eliminate the possibility that you have a tail of silence on the file or if there is, that you are triggering the next event with an EOM (end of message) marker at the end of the audio. Pull up a couple of the involved files to make sure that there are no tails and/or there is an EOM marker placed art the end of the audio.

What is your network topology?

If you are running an switch, router, or hub, I would investigate it for issues. You could have either packet loss, an intermittent cable connection or simply a router/switch/hub

Also check your network traffic. Is something causing excess traffic on your network?

 

[bossbill]

Dunno but will find out on a couple things you mentioned, but there are no tails, the files are all precise at correct lengths, :60,:30,etc. We've always made sure of that even before the iMediaTouch install, because we've always had satellite help with specific length stopsets on all our stations.

And the OMT system is on a separate LAN, with OMT server, and only 2 On-Air units being used currently. Between the two stations, the stopsets are at different times. So in any particular stopset, that's the only thing running in the whole system. The spots are all cued up in the "decks" but when they play, there are pauses between the audio files, on an inconsistent basis.

(Dave Haviland, if you're catching this, you may want to weigh in... you know more about the techy stuff.)

 

[SirRoxalot]

How much RAM is on the server? I'd recommend 4GB, and no less.

You could have a latency problem on your network. Do you have anyone who knows how to test network links? You're looking for a node that's generating lots of CRC errors, or seems to show data activity when it shouldn't. Twisted pair running through a high RF area, or near a source of EMI, could be the problem. Also, how long are your network segments? Remember, max on a segment should be about 330 feet, and there should be no more than three segments. Switch-to-switch-to-switch configurations can add a LOT of latency. And hubs shouldn't even be considered anymore.

Another thing that will slow a network down considerably is encryption.

One more thing - run a full CHKDSK on all of the systems involved. NTFS is wonderful at recovering data from bad sectors, and continuing to work when a hard drive has serious issues, but it will slow down. CHKDSK will require a reboot, and will take a 1/2 hour or more to complete, but it's the only way to determine if you have a file system error that's slowing down data delivery. If you have mirrored drives, make sure all drives in the array are functioning correctly.

 

[DudeFan]

It really does sound like a file-access issue due to the network.

He definitely needs to check the traffic and whether there are errors on the network.

I have had a router/switch go bad, so I would check the health of the router or switch too.

When I have had silence issues with iMediatouch, it has been caused by the inavailability or late availability of the file, such as when we Ghost the server drives overnight into Sunday.

 

[audiophile.]

I'd do a network performance test, what the response time of file and what the throughput.

Also virus scanners can really cause a drag (a ten-fold decrease has been noted in some cases). Try un-installing them, temporarily.

Lastly put the return liner at the end of the stopset, it will always sound better that way!

 

[OttoM]

Here's a simple test: Can you run the on-air computer with playing audio from a local (non-server) drive? If so, try that and see if your latency problem goes away. If you can't run the system without the server, well that's a different problem all together... ;D

 

[xmusicmatt]

I echo others advice. See if you can try to run the audio cuts locally on the on air machine (should be able too -- almost all systems have that option incase the networked file server is unavail.

Also, could it possibly be the drive is failing on the network server where the files are stored? Have you peeked into event viewer to see if there is anything out of the norm.

 

[bossbill]

Thanks to all for input. Most of the things mentioned either have been or will be addressed. It doesn't appear that we have issues with failing drives, the network, or the server.

OMT has now told us that the actual sound files should be longer than the commercial itself, so that the EOM is not exactly at the end of the sound file. For instance, on a :60 spot they want us to leave a tail on it, so that even though the audio runs :60, the file continues for a second, and then place the EOM at :60 exactly. This is a change in our age-old precedure of making a spot :60 with a file length of :60. I'm told that the system then sees a crossfade between two audio files and will work perfectly. I'm told that has to do with the way the drivers work and that if a file is ending simultaneously with the EOM, that we may experience a lag.

I'm an old relay automation guy. Does this make sense? We're redoing our commercial library to accommodate this.

 

[audiophile.]

Doesn't make a lot of sense to me.

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

 

[bossbill]

We had/have thought of making a return liner part of the stopset. A 3:30 stopset would then become 3:40 and a :10 liner would be the last element.

Traffic tells she she doesn't like that approach, because sometimes stopset are filled, sometimes empty, and it would take more work (for 4 stations) to add the liner only when a stopset is filled. The good news, however, would be that the network liner closure would still be activated, and would fire, but if the stopset were filled, that liner wouldn't play, because the one in the stopset would be playing.

First, we'll see if the OMT suggestion is the real deal. My IT guy thinks it may be, and we'll try anything to make it work right. There is nothing more frustrating than to upgrade to the current 21st century and find problems that did not exist with 15-year-old DOS products.

 

[VoiceOfReason]

We've been using iMediaTouch at my facility for a few years.

No matter how optimized, there is a tiny bit of reaction lag in the OnAir module. We ended up implementing a 1 second EOM policy on all spots, and they end up being tightly butted together during playback.

An easy test would be to look at an upcoming stopset (that isn't loaded into PTA's yet), and setting the EOM's of the involved spots in production to 1 sec. See how it plays out.

Also, we had them add an intro-protection feature a few years back that they never really understood or got right. Make sure that isn't enabled as it could see the 0 intro of the next spot and reset your EOM to the end of the cut to protect that upcoming 0 intro.

 

[bossbill]

VoiceOfReason, thanks for your suggestions.

I don't recall having this issue with other automation systems, but maybe I haven't dealt with enough newer ones. We've been spoiled by old DOS systems that have never had this issue, that play elements back-to-back all the time with never any lag, and perfectly timed, along with the failsafe feature of holding the return liner in case the stopset is slightly over for some reason.

Our first iMediaTouch system was installed last October, we have had the "lag" or "pause" since install, and we've been going crazy with workarounds (like adding deadroll to the return liner). It was only this week that we were asked to change our procedure and make sure the files were left longer, placing the EOM at the :30 or :60 mark, rather than making the files :30 and :60 with an EOM at the end.

This of course will be a little work for us to implement, but OMT tells us it will solve the problem.

I wonder is this only an issue for this one provider, or do other current systems have the same challenge?

 

[PTBoardOp94]

We use just a couple hundreths of a second for our EOM fade.

i.e. Audio runs 30.04 and the EOM is set at 30.00. iMediaTouch production handles this for us. Never noticed any problems with spots having delays in between. In fact, we usually go back to the network a little early - often because of sloppy board work on the network end

 

[VoiceOfReason]

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.

 

[ChiefOperator]

I maintain our iMediatouch system. We're running iMediatouch v3 now, but our set-up is a little different. We use four machines: on-air, production, logger, and traffic. On-air functions as our server.

We have no problems. Once we produce a spot, we'll stretch or compress slightly to make it exactly :30 or :60. This process will always make the :30 spot = :30.015 and the :60 = 1.00.004. We keep that length but set the EOM at 30.00.000 and 1.00.000. It works perfectly--no pauses and no problems.

While there is talk about spot lengths as your problem, I'm leaning toward a network issue. In troubleshooting this problem, I would first rule-out a network issue, especially before you start modifying your library.

Here is a process to isolate this problem as either a network problem or something else. As you know, when you create a new category on your production machine, those files are written to your server. What you should do is create a new test category, BUT create this new category directly on the on-air machine, not on the server (you may need to temporarily map a drive). Load some spots into the new category. Now, once the spots from this category air, they will play directly from the on-air machine--completely bypassing the server. See whether the pauses go away. If so, you have a network issue; if not, a different problem.

Good luck!