TestStand Deployment Issue - VI too early to convert

I have a test system which has LabVIEW 8.0 and TestStand 3.5 running VIs and sequences developed on this system. I am trying to replace this with a deployment system and not having much success. I admit I'm pretty green with LV8 and TS3.5, but reasonably computer savvy.
I purchased the same DAQ boards used in the existing system and installed them in a new PC. The PCs are different types, the existing system is a HP Pavilion and the deployment system is a Dell. I didn't think hat would have much effect.
I created a deployment install image on the development system. I tried this a few months ago and was able to get a simple test deployment working. Now that I've got the actual DAQ hardware, I attempted to deploy the full test system. It installed OK on the deployment system, but when I run a sequence, I get a message that states:
LABVIEW: VI version is too early to convert to the current LABVIEW version.
The notable differences between the two systems include:
1. Different PC types
2. Possibly a different DAQmx version - I installed DAQmx from the CDs that came with the new hardware, not from the original CDs.
3. XP Pro instead of XP Std
Any suggestions? Like I said, I don't have a lot of experience with this, so any help is appreciated.
Thanks,
Blair

Thanks, Rick. I tried checking Daqmx 8.0 as one of the drivers to load with the build and got an error. The error indicated that the driver couldn't be loaded as Measurement Studio wasn't installed.
I'll have to see if I can find the original drivers that were used with the old system and remove the drivers from the new system and install the old drivers. I suppose I could try installing the new drivers on the old system and then doing the build, but I hesitate to do that as I am afraid that something will get broken on the old system and shut down production. I've already had one issue during start-up that caused the license to invalidate and had to re-install the license, so I would rather not make any changes at this time.
Unfortunately, a subcontractor created the original system, and I don't know if I have the original driver disks.
The driver disks that came with the new DAQ boards show ver 8.6.
The version number of Measurement and Automation Explorer is the same.
Blair

Similar Messages

TS4.2: VI too early to convert

Hi,
I'm getting the error -18002 VI too early to convert when I execute a TestStand 4.2 sequence file with the TestStand Base Deployment Engine. I created the Deployment installer with the deployment tool in TS4.2 and installed it on a second system. I added all needed LV runtimes and drivers incl. TestStand Deployment Engine. All installed softwares shown in the MAX are equal to the Developing system. But on the target system I always get the mentioned error. So I searched the NI Forum and found a similar Problem, but no real solution for that. I think, that the TestStand Base Deployment Engine on the target system chooses the wrong LV runtime engine, something higher then 8.2.1 (this is the version of the VI's). When I change the Labview adapter the the developing system to 8.6.1, I get the same error. But with 8.2.1, everything works fine.
How can I change the default LabView Runtime Version for the TestStand Base Deployment Engine?
Thnaks in Advanced
M. Tiedje
Solved!
Go to Solution.

mtimti wrote:
[...]I need a something like the LabView Adapter (like in TestStand developing system) in the TestStand Base Deployment System.[...]
The TestStand deployment has also settings for Adapters. It is possible, that your UI does not supply you with the option to change those settings. You can always install the predefined UIs delievered with TestStand and run it on the deployment system. You can then change the settings for the LV Adapter as needed.
mtimti wrote:
[...]All my settings and software version are identical on both systems.[...]
If this is true, then the LV Adapter settings should already be correct. Therefore, there has to be another reason for this behavior. But please check the settings as described before.
mtimti wrote:
[...]The whole problem started when we decided to change the TS version form 3.5 to 4.2. everything was fine with 3.5 and I thought I only need to deploy everything again and that's it, bau then came the VI version error.[...]
Never heared something like this. I asume that not only TestStand was updated in the process. Is it possible, that you have been working with something older than LV 8.2 when using TS 3.5? If so, please masscompile all VIs using 8.2 before deploying them.
hope this helps,
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

TestStand Deployment Issues

Right now we are in the process of building deployment packages for our test stations in TestStand. We basically have some model customizations as well as the actual client sequence file, which calls VI's. These VI's do have sub-VI's which are distributed with the package. I can get the whole package to deploy (both install and image files), but when I try to run the deployed package on the target computer using a customized user interface, I recieve error -18001. The error dialog box informs me that the VI cannot be run, because the NI LabView Development System cannot be found. In my client sequence file I went through all the VI's and made sure they always run in runtime mode. I also set the LabView adapter on my development computer to runtime v8.5 for when I deploy. I'm quite baffled at this point as to why I'm still having issues. Could it be an issue with my user interface instead, or how do I remedy this issue?
Message Edited by schm1347 on 10-26-2007 10:42 AM

Hi, schm1347,
The adapter info is stored in <TestStand>\cfg\TestExec.ini file. So when you make your deployment, you should include this file and deploy it to the same folder on the target computer, as shown in the attached screenshot.
In general, if you want to keep the TestStand settings on the target machine the same as the development computer, you should include the cfg folder. It includes user management, station global, execution options, etc.
Regards,
Song D
Message Edited by Song D on 10-29-2007 11:36 AM
Regards,
Song Du
Systems Software
National Instruments R&D
Attachments:
ss.JPG ‏72 KB

Sypris Teslameter Driver_too early to convert to 8.5 labview version

I am new to labview (8.5) programme and trying to use it to run my setup. I connected the Gaussmeter/Teslameter (FW Bell Sypris 6010) to the computer using serial port and RS-232 cable and used the driver (from the company) for this type of devices in order to allow labview to communicate with this device but there is always an error when I try to access the device through labview. This error says:
"VI version is too early to convert the current LabView version"
I would really appreciate any help in getting this solved.
Many thanks
Hadiq
Islam means peace
Solved!
Go to Solution.
Attachments:
FWB6010.zip ‏412 KB

Thanks for your suggestion. I did it and hope to get it sorted.
Many thanks,
hadiq
Islam means peace

Labview load error code 10:VI version (8.2b23) is too old to convert to the current

trabajo en la version de LabVIEW 8.2, 20th aniversary edition, Professional y cuando intentaba abrir la parte de examples en la primera ventana me aparecia el siguiente error:
LABVIEW:VI version is too early to convert to the current labview version.
An error occurred loading VI "find examples.vi".
Labview load error code 10:VI version (8.2b23) is too old to convert to the current
labview version (8.2.1f4)
luego de la primera intaslacion de la version 8.2b23 tambien me salia el mismo error, desintale y reinstale pero igual, asi que probe instalar un parche que actuliza a la version 8.2.1f4, pero como ven sigo con el mismo problema ademas de intentar mass compile pero no me funcina al parecer son muchos VIs que hay que compilar... tambien busque el LabVIEW conversion kit, pero son para versiones demasiado anteriores agradeceria me ayudaran a solucionar este problema.
MUCHAS GRACIAS
ATT: Carlos Andres Rosero, Colombia

According to this, 8.2b23 is an illegal, bootlegged copy of LabVIEW.

TestStand Deployment problems with visarc issues

Recently I attempted to rebuild a TestStand Deployment that I had build just 1 month before and it wouldn't create the deployment. Changes that occurred between the last build and this build was an upgrade to LV 8.6.1 from LV 8.6.
The issue was that the file visarc was not able to be found by the deployment engine and wouldn't progress much beyond the tsw file verification. It turned out that having multiple versions of LV on my harddrive screwed up the linking on this file and caused the deployment to fail.
The following link solved the issue and allow the deployment to be built:
http://digital.ni.com/public.nsf/allkb/833BFD5E9CA0224886257584004DAA4C
I don't really have a question, just wanted to get this out there so fewer people have to sustain the pain that I went through.

Thanks for the input
Regards
Ray Farmer
Regards
Ray Farmer

Songs ending too early

It seems that since the last update to I Tunes some songs are ending too early (30 to 1:30 too ealry). The get info button does not indicate the songs should end early. When i download the song again, the problem stops.

There could be a number of causes. If the iPod only plays a very short part of the file <10 secs this is usually down to problems with the structure of the file that iTunes can cope with but that causes the iPod to bail out. Re-encoding in iTunes will normally help, ie. re-rip or convert from MP3 to AAC or vice versa. Since all transcoding is lossy you should retain your original file as a backup in the hope that future firmware upgrades will fix this issue. iTunes also has a feature to allow you to exclude parts of a song from being played. Use *Get info* on a song in question and look at the Options tab. There are options here to set a start & stop time and to remember the playback position. Setting any of these will affect what gets played each time the track is selected. Finally, if you're playing songs in random order that are part of continous play albums the exact point at which the track stops may not be quite where you expect it to be.
tt2

Labview version 7.1 is too old to convert to current Labview version 8.0

I had developed my Labview code sometime back using LV-7.1 and now I am trying to deploy it on a new PC. The Test Stand version that I have is 3.1. I did everything right and after I installed my deployment package, I get the error that the Labview version 7.1 is too old to convert to current Labview version 8.0.
I am going to look into converting my code using Labview 8.0, but I am puzzled, why would it matter, as am using the same Labview (7.1) and TestStand (3.1) as before, and getting this error? I also installed the old Traditional DAQ drivers (instead of the DAQmx) and so everything is the same except that the PC is new.
Shoab
Attachments:
ErrorMessage.jpg ‏225 KB

Hey Shoab,
Are you getting this when you run the sequence in the Sequence Editor? If so then I would suggest checking the adapter configurations. Go to Configure>>Adapters select LabVIEW and click the Configure.. button. Once in there you can change the run-time engine to 7.1.
Let me know if that helps.
Regards,
jigg
CTA, CLA
teststandhelp.com
~Will work for kudos and/or BBQ~

Windows TCP Socket Buffer Hitting Plateau Too Early

Note: This is a repost of a ServerFault Question edited over the course of a few days, originally here: http://serverfault.com/questions/608060/windows-tcp-window-scaling-hitting-plateau-too-early
Scenario: We have a number of Windows clients regularly uploading large files (FTP/SVN/HTTP PUT/SCP) to Linux servers that are ~100-160ms away. We have 1Gbit/s synchronous bandwidth at the office and the servers are either AWS instances or physically hosted
in US DCs.
The initial report was that uploads to a new server instance were much slower than they could be. This bore out in testing and from multiple locations; clients were seeing stable 2-5Mbit/s to the host from their Windows systems.
I broke out iperf
-s on a an AWS instance and then from a Windows client in the office:
iperf
-c 1.2.3.4
[ 5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55185
[ 5] 0.0-10.0 sec 6.55 MBytes 5.48 Mbits/sec
iperf
-w1M -c 1.2.3.4
[ 4] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55239
[ 4] 0.0-18.3 sec 196 MBytes 89.6 Mbits/sec
The latter figure can vary significantly on subsequent tests, (Vagaries of AWS) but is usually between 70 and 130Mbit/s which is more than enough for our needs. Wiresharking the session, I can see:
iperf
-c Windows SYN - Window 64kb, Scale 1 - Linux SYN, ACK: Window 14kb, Scale: 9 (*512)
iperf
-c -w1M Windows SYN - Windows 64kb, Scale 1 - Linux SYN, ACK: Window 14kb, Scale: 9
Clearly the link can sustain this high throughput, but I have to explicity set the window size to make any use of it, which most real world applications won't let me do. The TCP handshakes use the same starting points in each case, but the forced one scales
Conversely, from a Linux client on the same network a straight, iperf
-c (using the system default 85kb) gives me:
[ 5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 33263
[ 5] 0.0-10.8 sec 142 MBytes 110 Mbits/sec
Without any forcing, it scales as expected. This can't be something in the intervening hops or our local switches/routers and seems to affect Windows 7 and 8 clients alike. I've read lots of guides on auto-tuning, but these are typically about disabling scaling
altogether to work around bad terrible home networking kit.
Can anyone tell me what's happening here and give me a way of fixing it? (Preferably something I can stick in to the registry via GPO.)
Notes
The AWS Linux instance in question has the following kernel settings applied in sysctl.conf:
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.ipv4.tcp_rmem = 4096 1048576 16777216
net.ipv4.tcp_wmem = 4096 1048576 16777216
I've used dd
if=/dev/zero | nc redirecting to /dev/null at
the server end to rule out iperfand
remove any other possible bottlenecks, but the results are much the same. Tests with ncftp(Cygwin,
Native Windows, Linux) scale in much the same way as the above iperf tests on their respective platforms.
First fix attempts.
Enabling CTCP - This makes no difference; window scaling is identical. (If I understand this correctly, this setting increases the rate at which the congestion window is enlarged rather than the maximum size it can reach)
Enabling TCP timestamps. - No change here either.
Nagle's algorithm - That makes sense and at least it means I can probably ignore that particular blips in the graph as any indication of the problem.
pcap files: Zip file available here: https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.zip (Anonymised
with bittwiste, extracts to ~150MB as there's one from each OS client for comparison)
Second fix attempts.
I've enabled ctcp and disabled chimney offloading: TCP Global Parameters
Receive-Side Scaling State : enabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : enabled
Initial RTO : 3000
Non Sack Rtt Resiliency : disabled
But sadly, no change in the throughput.
I do have a cause/effect question here, though: The graphs are of the RWIN value set in the server's ACKs to the client. With Windows clients, am I right in thinking that Linux isn't scaling this value beyond that low point because the client's limited CWIN
prevents even that buffer from being filled? Could there be some other reason that Linux is artificially limiting the RWIN?
Note: I've tried turning on ECN for the hell of it; but no change, there.
Third fix attempts.
No change following disabling heuristics and RWIN autotuning. Have updated the Intel network drivers to the latest (12.10.28.0) with software that exposes functioanlity tweaks viadevice manager tabs. The card is an 82579V Chipset on-board NIC - (I'm going to
do some more testing from clients with realtek or other vendors)
Focusing on the NIC for a moment, I've tried the following (Mostly just ruling out unlikely culprits):
Increase receive buffers to 2k from 256 and transmit buffers to 2k from 512 (Both now at maximum) - No change
Disabled all IP/TCP/UDP checksum offloading. - No change.
Disabled Large Send Offload - Nada.
Turned off IPv6, QoS scheduling - Nowt.
Further investigation
Trying to eliminate the Linux server side, I started up a Server 2012R2 instance and repeated the tests using iperf (cygwin
binary) and NTttcp.
With iperf,
I had to explicitly specify -w1m on both sides
before the connection would scale beyond ~5Mbit/s. (Incidentally, I could be checked and the BDP of ~5Mbits at 91ms latency is almost precisely 64kb. Spot the limit...)
The ntttcp binaries showed now such limitation. Using ntttcpr
-m 1,0,1.2.3.5 on the server and ntttcp
-s -m 1,0,1.2.3.5 -t 10 on the client, I can see much better throughput:
Copyright Version 5.28
Network activity progressing...
Thread Time(s) Throughput(KB/s) Avg B / Compl
====== ======= ================ =============
0 9.990 8155.355 65536.000
##### Totals: #####
Bytes(MEG) realtime(s) Avg Frame Size Throughput(MB/s)
================ =========== ============== ================
79.562500 10.001 1442.556 7.955
Throughput(Buffers/s) Cycles/Byte Buffers
===================== =========== =============
127.287 308.256 1273.000
DPCs(count/s) Pkts(num/DPC) Intr(count/s) Pkts(num/intr)
============= ============= =============== ==============
1868.713 0.785 9336.366 0.157
Packets Sent Packets Received Retransmits Errors Avg. CPU %
============ ================ =========== ====== ==========
57833 14664 0 0 9.476
8MB/s puts it up at the levels I was getting with explicitly large windows in iperf.
Oddly, though, 80MB in 1273 buffers = a 64kB buffer again. A further wireshark shows a good, variable RWIN coming back from the server (Scale factor 256) that the client seems to fulfil; so perhaps ntttcp is misreporting the send window.
Further PCAP files have been provided, here:https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zip
Two more iperfs,
both from Windows to the same Linux server as before (1.2.3.4): One with a 128k Socket size and default 64k window (restricts to ~5Mbit/s again) and one with a 1MB send window and default 8kb socket size. (scales higher)
One ntttcp trace
from the same Windows client to a Server 2012R2 EC2 instance (1.2.3.5). here, the throughput scales well. Note: NTttcp does something odd on port 6001 before it opens the test connection. Not sure what's happening there.
One FTP data trace, uploading 20MB of /dev/urandom to
a near identical linux host (1.2.3.6) using Cygwin ncftp.
Again the limit is there. The pattern is much the same using Windows Filezilla.
Changing the iperf buffer
length does make the expected difference to the time sequence graph (much more vertical sections), but the actual throughput is unchanged.
So we have a final question through all of this: Where is this limitation creeping in? If we simply have user-space software not written to take advantage of Long Fat Networks, can anything be done in the OS to improve the situation?

Hi,
Thanks for posting in Microsoft TechNet forums.
I will try to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.
Thank you for your understanding and support.
Kate Li
TechNet Community Support

Outlook displays date of birthdays one day too early in MS Office 2007, 2010 and 2013

Hi
We are supporting several clients that has issues with Outlook. Different versions of Windows, Office and different exchange server versions. Some contacts' birthdays
just "magically" changes to one day too early. I have done extensive research with no answer. I have experienced this issue personally as early as about 2005 or 2006 with a Windows Mobile PDA.
Our local time is GMT +2 without daylight-savings. I have checked the settings in Windows (Vista Pro and Win 7 pro
x86 and x64) and the calendar settings, I have reloaded a couple of pc's, created new profiles, installed new server hardware with newer exchange. Even tried a few off-the-wall ideas like resetting all views to default.
Some users' address books are shared, some not. Some uses Apple, Android, BB or Windows phone, some don't. Some connects through VPN, some don't. Some uses
AVG, Avast, Eset Nod, Forticlient, Mcafee, etc....
I have been fighting this problem for months, and can find no conclusive answer that resolves this.
If I manually open the contact and rectify the date, it will stay correct for a very random time period and then shift
again.
I am about to lose a couple of my biggest clients, and probably my job as well, so I need urgent help.
Please no remarks on OS version, Office version or mobile devices, as this is definitely not the issue.
HELP!

Hi,
Have the users check on OWA, does the issue persist? Please also make sure the timezone of Exchange is also properly configured.
I'm not an expert about Exchange, I hope this blog can be helpful:
http://blogs.technet.com/b/fun_with_powershell/archive/2013/04/30/where-is-the-time-zone-property-stored-in-exchange-2010.aspx
To further dig the problem, rectify the date on owa and drop Outlook for a while(or one day), check the result the next day if the problem will come back.
Regards,
Melon Chen
TechNet Community Support

Is it too early to start with JavaFX Mobile Development ?

There are no developer compnents except "TextBox"
The only samples i can see are "showing Photos in grid like structure & similar kinds of app" :(
it doesn't even support Swing
What developer wants "Data Entry Form" which user will submit data to Server Or Store data To Database & then Process the Data & return Result to user, Etc & much more req
why javaFx is more Media Oriented( Audio, Video,Graphics,Animation,Games,etc)
What benifits it provides to Developer.I am basically targetting JavaFX Mobile
Please Reply to help me understand What Can I do In JavaFx mobile domain
Thanks & Regards,
Pravin

Hello, and Welcome to the HP Support Community! As with any Internet Forum, you have to realize that you are visiting a "hospital" - most folks here are the minority who have had problems. If one was to judge the human race by visiting a hospital, you might run outside screaming "WE'RE ALL DOOMED! EVERYONE HERE IS SICK!!!" Those who have no issues at all do not come here and check in. The few that actually do come by and offer compliments are far and few between, and they are greatly appreciated by us! I've asked HP about Win10. They will not provide an answer until the final release is out. It could run with zero issues, or not! The Sprout is an amazing device - a large touchscreen All In One computer with some cool options not many other PC's could ever do! Is it too early? I've had one for almost a year (a loaner from HP for my participation here). Glitches? A few that were easily remedied. The decision is up to you. If worried about Win10, then wait a month or two. The device runs fine on Win 8.1. Why change to Win10? WyreNut

Safari gives up loading images too early

Hi
I have noticed that Safari (currently I am using 3.1.1 but I had noticed this behavior on earlier versions as well) usually gives up on loading images too early.
I have a 30Mbps internet connection and also in Firefox and Opera I do not experience the same problem.
Is this a known issue? Are there currently any workarounds around this problem?
Regards,
Behrang

From your Safari menu bar click Safari > Preferences then select the Privacy tab.
Click: Remove All Website Data
Then delete the cache.
Open a Finder window. From the Finder menu bar click Go > Go to Folder
Type or copy paste the following
~/Library/Caches/com.apple.Safari/Cache.db
Click Go then move the Cache.db file to the Trash.
Quit and relaunch Safari to test.
If nothing above helped, troubleshoot Safari extensions.
From the Safari menu bar click Safari > Preferences then select the Extensions tab. Turn that OFF, quit and relaunch Safari to test.
If that helped, turn one extension on then quit and relaunch Safari to test until you find the incompatible extension then click uninstall.

Preflight droplet returns too early

I want to convert a color PDF into grayscale. So I created a new preflight profile where nothing happens except color fixup:
Advanced > Print Production > Preflight
PDF Fixups > Convert to Grayscale
I saved the profile and created a Droplet named grey.exe.
When I call grey.exe smallSize_1MB.pdf everything is fine. But when I have to convert a PDF having big filesize like grey.exe bigSize_160MB.pdf the Droplet .exe process returns before the preflight is done.
Problems: A script (e.g. a batch file) continues without waiting for the Droplet to finish. So the script cannot make use the Droplet's result, e.g. a preflight report or the converted PDF file.
Why does the Droplet's .exe process return too early? Everybody can test this with the help of the attached Droplet and the following batch scripts:
smallSize.bat (use something small, e.g. 1 MB or smaller):
copy /Y smallSize.pdf tmp.pdf
grey.exe tmp.pdf
echo "return"
pause
bigSize.bat (use something really big, e.g. 160 MB or bigger):
copy /Y bigSize.pdf tmp.pdf
grey.exe tmp.pdf
echo "return"
pause
Ideas, anyone?
Message was edited by: Droptix I am using Adobe Acrobat 8.0 Professional.
Message was edited by: Droptix As an alternative I can imagine to re-produce the Droplet's function by Interapplication communication (IAC) through OLE, see http://www.adobe.com/devnet/acrobat/interapplication.html -> if anyone can tell me how to do a grayscale conversion via IAC/OLE... would be great! I know the IAC/OLE basics, can open, save and edit PDFs but don't know how to convert. It would also be possible to use: Advanced/Print Production/Convert Colors > set all Document Colors to convert > set Blending profile for instance to Gray Gamma 1.8 > set conversion options to don't embed profile.

This is not a good way to do it. But this is the way I do it now...
It seems to work but there is no guarantee that it will work in the future, or even on all machines.
private static int WaitForAcrobatReady() {
// Get the current Acrobat instance.
var app = new Acrobat.AcroApp();
// While a preflight (droplet) is running, app.GetNumAVDocs() will
// not return ANYTHING, it will just hang.
return app.GetNumAVDocs();
To sum up the efforts of the last weeks: Acrobat doesn't seem to be made for inclusion in other automation jobs. This is just another thing that doesn't work.
(I had to use the C# library PDFSharp to do other things that Acrobat can do really well only that it's not possible to set those properties, or start that kind of actions, from "outside".)

Folder action kicks in too early

I have a little applescript that is to add all files that are added to a specific folder to an iTunes playlist.
I added the script as a folder action to the folder.
It seems to work fine with single files.
However, when I copy several files (which takes a few seconds), then the script gets started too early, i.e., when only half of the files have been copied over. Consequently, only some of the files get added to the playlist.
In addition, when I copy a large number of files, it doesn't seem to work at all.
Any ideas what's wrong? or what I can do?
(Is this a bug in Mac OS? I read about an issue in 10.5 where folder actions got started before a single files was finished copying, but I haven't seen of any hints about my problem.)
Any kind of help will be highly appreciated.
Best regards,
Gabriel.
PS:
Here is my script, for completeness
Automatically add the files that are dropped on this applescript to
playlist named below.
To adapt it for a different playlist, just change the name below and save as application.
In addition, you can add this script as a folder action
Author: Gabriel Zachmann, Feb 2010
property playListName : "Hoerspiele"
on open theseFiles
addTheFiles(theseFiles)
end open
on adding folder items to this_folder after receiving added_items
addTheFiles(added_items)
end adding folder items to
to addTheFiles(theFiles)
tell application id "com.apple.iTunes"
activate
set playL to some playlist whose name is playListName
set playID to persistent ID of playL
--display dialog ("persistent ID = " & playID) buttons {"OK"} default button 1
reveal (some playlist whose persistent ID is playID)
repeat with aFile in theFiles
try
add aFile to some playlist whose persistent ID is playID
end try
-- set new date, so we know later when we copied the files
set the file_path to the quoted form of the POSIX path of aFile
do shell script ("/bin/touch " & file_path)
end repeat
end tell
end addTheFiles
Message was edited by: GabrielZ

folder actions have always been buggy and this has always been an issue when folder actions have to process many files at the same time. it's supposed to have gotten better in snow leopard but it's still very far from being reliable. you can try the following trick to slow down your folder action and make it wait to process individual items before they are all copied. that might (or might not ) help
http://discussions.apple.com/message.jspa?messageID=8277780#8277780

GCU membership set to expire 11 months too early

Hello! I'm posting here about an issue with my Gamer's Club Unlocked membership. These snippets of my emails to Best Buy Customer Support should explain my problem:
12/19/2013
Me: I just renewed my Best Buy GCU membership for an additional two years, but my problem is that those two years did not stack with the remaining time on my previous one year membership, which did not expire until February 10, 2014. My newly-renewed membership says it will expire on December 18, 2015, but it should not expire until February 10, 2016. Will you please fix this?
Date unknown
Me: I renewed my GCU membership last December, but I haven't received the physical magazine in the mail since then, nor have I ever received any of the digital version's coupons.
02/25/2014
Support: I suggest you to go at the store and they will be more than glad to assist you with your concern.
Date unknown
Me: I already tried asking the store manager at my nearest Best Buy for help with this multiple times. She said there was nothing she could do, and to contact online customer support. You're the third online customer support Rep to suggest I go back to the store for help. I'm tired of getting bounced back and forth...
02/27/2014
Support: We are experiencing system maintenance, reason why it is reflecting that date. As soon as it is over, the correct date will be reflected on your account.
Date unknown
Me: It's now been about a week and a half since your most recent reply, and my Gamer's Club Unlocked memberships is still set to expire on December 18, 2015, when it should not expire until February 10, 2016. Surely "system maintenance" wouldn't be going on this long... I asked the store manager of my nearest Best Buy one more time if she could help with this -- once again, she said no. Will this ever get fixed? Or am I just stuck with losing two months of my membership?
03/11/2014
Support: In regard to your concern, we were having system maintenance issue however, you will not loose two months of your membership it will expired the date it should be.
03/12/2014
Me: I just checked my account, and now my Gamer's Club Unlocked membership is set to expire on 3/10/2015. It's even worse now than it was before! Now it's set to expire 11 months too early. My GCU membership should not expire until 02/10/2016.
03/12/2014
Support: We have escalate this case to our support department. This process will take 7 to 10 business day and they will contact you with a resolution to your concern.
Nearly 4 months later, I have not received any further messages from Customer Support, and my GCU membership is still set to expire 11 months too early. Would someone here please help me with this?

Hey Bent_00,
As enuf mentioned, your patience is absolutely incredible and I sincerely thank you for it. It’s clear to me that you’ve spent a significant amount of time working with our support representatives in regards to your Gamers Club Unlocked (GCU) membership expiration date. While I greatly thank you for joining GCU, I do apologize for any confusion you’ve endured about when your benefits should expire.
This is in fact a known issue and our My Best Buy team has been working to resolve the issues causing your expiration date to reflect incorrectly. While some GCU members are now seeing their correct expiration date, we are aware that some may still be incorrectly reflecting. As enuf further alluded to, we are very confident that this will be resolved well before your GCU benefits would ever expire.
I appreciate you sharing your concerns with us on the forums. If you have any other questions, please don’t hesitate to ask! Thanks again for being a GCU member.
Best regards,
Brian|Senior Social Media Specialist | Best Buy® Corporate
Private Message

TestStand Deployment Issue - VI too early to convert

Similar Messages

Maybe you are looking for