I am using Instaloader via command line on Windows 11, with the following command:
.\instaloader --login=MYUSERNAME :saved --dirname-pattern="Saved_Posts\{profile}" --filename-pattern="{profile}-{shortcode}" --no-resume --no-metadata-json --slide 1 --no-captions --no-video-thumbnails --no-iphone
This attempts to download approximately 12,000 saved posts from a profile. Instaloader behaves as expected for several thousand posts, occasionally giving the following error:
Too many queries in the last time. Need to wait 15 seconds, until 13:19.
The process then resumes successfully for several hundred more posts. Eventually, however, I start encountering 429 errors:
JSON Query to graphql/query: 429 Too Many Requests [retrying; skip with ^C]
Number of requests within last 10/11/20/22/30/60 minutes grouped by type:
d6f4427fbe92d846298cf93df0b937d3: 0 0 0 0 0 0
f883d95537fbcd400f466f63d42bd8a1: 0 0 0 1 1 11
* 2b0673e0dc4580674a88d426fe00ea90: 59 64 121 134 191 709
Instagram responded with HTTP error "429 - Too Many Requests". Please
do not run multiple instances of Instaloader in parallel or within
short sequence. Also, do not use any Instagram App while Instaloader
is running.
The request will be retried in 7 seconds, at 14:01.
This error then repeats over and over again, I believe until the default maximum connection attempts limit is reached and it moves onto the next post — which also receives the same error. Importantly, this error does not go away after several hours of these 'slower' requests being made; it seems to persist as long as Instaloader stays open. I have seen these 429 errors with very few requests in the last 60 minutes (i.e. <100), which makes me think I am hitting quite a long shadowban.
I have tried setting the maximum connection attempts to 0 (i.e. retry indefinitely), but this time limit appears to be capped at 666 seconds, or 11 minutes. The error does not seem to clear even leaving Instaloader to send requests every 11 minutes in this way; it is as though each individual request 'resets' the ban or something.
I am looking for a way of resolving this issue, which could include:
Adding a command to force 429 errors to be retried after subsequently longer periods of time (instead of the number of seconds being capped at 666 seconds)
Adding a command that 'preserves' wait times after each 429 error. e.g. if downloading Post 456 fails and retries after 5, then 10, then 15 seconds before successfully downloading, and then downloading Post 457 immediately fails... start the wait for a retry on Post 457 at at LEAST 15 seconds, rather than going back to 5!
Avoiding the 429 errors in the first place, if there appears to be an issue with my command line prompt
Breaking down the request into 'batches' and running one of those prompts every few days. e.g. is there a way to download Saved Posts 1-500, then 500-1000, and so on? (The Saved Posts are not necessarily in chronological order of the post date, which is what I've tried so far)
I have looked at several other posts on 429 errors but the general theme seems to be either:
Wait some time for the issue to clear — have tried this for up to 48 hours, but running the command again starts from post #1 and never makes it to the latter half of posts
Disable iPhone API requests — already done, which helps but does not solve the issue
The 429 errors simply should not be encountered during normal behaviour – well, they are!
I wrote an AppleScript to synch my Reminders (via export to JSON). It runs great... from the Script Editor. As soon as I tried to run it on the command line via osascript, I discovered it hits a wall when it tries to access reminders. After maybe a minute and a half, I get this error:
/Users/robleach/Temporary/synchRemindersTest.scpt: execution error: Reminders got an error: AppleEvent timed out. (-1712)
I also noted these errors in the console:
error 19:33:49.628309-0400 tccd Refusing client without path (from responsibility_get_responsible_audit_token_for_audit_token) PID[1422]: (#3) No such process
error 19:33:49.628370-0400 tccd Refusing TCCAccessRequest for service kTCCServiceReminders from invalid client with pid 1422
Assuming it was a permissions issue, I looked in System Preferences>Security & Privacy>Reminders, and noted that osascript is not there, nor do I have ± buttons to add it, even after authenticating.
I wondered whether saving the script as an app would prompt the Security stuff to prompt me to enable it - and that I could cron the opening of that app, but if I do that, I won't be able to pass arguments to the script (or at least, I don't know how to do that). Plus, I'd rather everything happen in the background, without a dock icon or anything (aside from the Reminders app needing to be open).
I wrote a toy example of the script that produces the timeout error:
TOY 1
tell application "Reminders"
return (properties of every reminder whose completed is false)
end tell
And I call it like this:
> osascript /Users/robleach/Temporary/synchRemindersTest.scpt
Is there a way to allow the osascript run of the script to be allowed access to the reminders? Could I like code-sign the command line executable or something? If I were to write this in another language, would it have the same issue?
I'm running Catalina 10.15.7.
UPDATE 1
I dug some more into the console. There are number of other, potentially relevant errors. I think it actually is a timeout. When I run it in Script Editor, it runs in about 40 seconds, but it times out when I run it via osascript (at maybe around a minute and a half).
However, I recalled that I have another script on a cron job that accesses reminders, and I did not remember it having an issue. So I tested it, and for whatever reason, it executes a very similar command, but succeeds. And it runs much faster in the Editor than it does on the command line from osascript. I pulled that one line out of that script that succeeds and wrapped it in a toy script:
TOY 2
tell application "Reminders"
set theList to "ToDo Home Recurring"
set namesDates to {name, due date} of (every reminder in list theList whose completed is false)
display dialog "Got " & (count of namesDates) & " reminder names & dates"
end tell
and it failed via osascript with the same timeout error. Then I pulled out another line and added it to the toy:
TOY 3
tell application "Reminders"
set theList to "ToDo Home Recurring"
show list theList
delay 0.25
set namesDates to {name, due date} of (every reminder in list theList whose completed is false)
tell application "System Events" to display dialog "Got " & (count of namesDates) & " reminder names & dates"
end tell
...it succeeds. So I don't think this is a permissions issue any longer. This feels like it maybe has to do with how efficiently osascript accesses Reminders.
I also started noticing that my first toy example above sometimes fails when run from the script editor. I kept retrying it to get the running time I pasted above and I started to sense a pattern. I think that when I select a new list to view in the Reminders GUI (it doesn't matter which one), then run the script (from the editor), it works. But if I don't select a new list to view and run the script from the editor again, it fails with that timeout.
...but that seems nuts. Can anyone explain what's going on here?
NOTE: The script I'm writing is actually an AppleScript re-write of a Siri Shortcut I wrote (that runs reliably in around 25ish seconds). Since I wanted to automate it and run it more than once a day, I decided to use AppleScript.
UPDATE 2
I tried the answer suggested by #Robert Kniazidis.
TOY 4 (modification of TOY 1)
with timeout of 3600 seconds
tell application "Reminders"
set allRems to (properties of every reminder whose completed is false)
display dialog "Got " & (count of allRems) & " reminders"
end tell
end timeout
...and kept a closer watch on the console.
Attempt 1 (TOY 4)
I ran TOY 4, starting at 7:25:24, for 10 minutes, then control-c'd it. I immediately saw numerous errors in the console. I searched the console for "Reminders" and here's what I go during the run.
Attempt 2 (TOY 4)
Then, given my insights regarding my annecdotal successes when I click a list name in the Reminders GUI, I tried clicking on a random list and ran TOY 4 again immediately after. I started TOY 4 at 7:38:23. At 7:44:22, it succeeded! That's about 6 minutes!
The console had many fewer messages in it, none of them marked as error. For comparison's sake, here are the console results from searching for "Reminders".
Discussion
I have revised my theory about what's happening. Given the console messages, I infer that when you run by osascript from the command line, the script is identified as "indirect access", and as such, is subject to a higher level of security-scrutiny, thus is takes much longer to execute. Perhaps when I "click in the GUI" (or even via AppleScript, show list theList), the security concern is still considered "indirect", but is not totally unknown to the user because the GUI is changing, so is subject to somewhat less scrutiny, and thus takes 6 minutes as opposed to somewhere over 10 minutes.
If that's true, it is interesting to note that that lesser level of scrutiny is applied even if the Reminders GUI is on a different desktop (as has been the case in my tests*).
UPDATE 3
I tried ad-hoc code-signing this morning with:
codesign --force -v -s - synchRemindersTest.app/Contents/Info.plist synchRemindersTest.app/Contents/PkgInfo synchRemindersTest.app/Contents/Resources/applet.rsrc synchRemindersTest.app/Contents/Resources/Scripts/main.scpt synchRemindersTest.app/Contents/Resources/applet.icns
...and ran the app again, which was a version of TOY 1. Still got the timeout error. I was hoping it would take 40s, like when run from the script editor. When I get time, I'll try it again but manually select a list in the Reminders GUI.
UPDATE 4
I ran the same toy as in update 3 again just now. For the 2 minutes it ran before the timeout, the console was filled with 52,349 lines of mostly this, repeating over and over, which is only the portion of that timespan that matched the search term tccd.
I also have noted that the same unmodified script, run at different times, will succeed in some runs and fail on others. Such as:
TOY 5 (synchRemindersTest5.scpt)
with timeout of 600 seconds
tell application "Reminders"
show list "ToDo Home"
set startt to (get current date)
set allRems to (properties of every reminder whose completed is false)
set endt to (get current date)
set dur to (endt - startt)
set msg to "Got " & (count of allRems) & " reminders in " & dur & " seconds"
tell application "System Events" to display dialog msg giving up after 5
return msg
end tell
end timeout
I ran it repeatedly yesterday, successfully, but I get the timeout when I run it today:
[Jun 08 22:59:51]:~/GoogleDrive/Scripts>osascript synchRemindersTest5.scpt
Got 166 reminders in 287 seconds
[Jun 08 23:06:17]:~/GoogleDrive/Scripts>osascript synchRemindersTest5.scpt
Got 166 reminders in 291 seconds
[Jun 08 23:11:45]:~/GoogleDrive/Scripts>osascript synchRemindersTest5.scpt
Got 166 reminders in 293 seconds
[Jun 08 23:17:46]:~/GoogleDrive/Scripts>osascript synchRemindersTest5.scpt
Got 166 reminders in 300 seconds
[Jun 09 8:23:28]:~/GoogleDrive/Scripts>osascript synchRemindersTest5.scpt
synchRemindersTest5.scpt: execution error: Reminders got an error: AppleEvent timed out. (-1712)
Footnotes
* I've been testing my scripts intentionally with the Reminders app on a different desktop because I have noted in my efforts that GUI scripting is always faster than accessing via the Reminders dictionary. So I wrote 2 methods: GUI and Reminders Dict. The GUI one will run if the open Reminders app is on the desktop (which I keep tucked under the dock). If we're watching Netflix full screen, I have a try/catch to use the slower Reminders Dict access method when the GUI is, as in that case, on a different desktop.
Wrap your script with timeout of 3600 seconds (1 hour). Your script time outs with default time = 2 minutes (120 seconds) per command. So,:
with timeout of 3600 seconds -- or 600 seconds, or as you want
tell application "Reminders"
return (properties of every reminder whose completed is false)
end tell
end timeout
Seing your TOY 4 once again. Man page of osascript says: Any arguments following the script will be passed as a list of strings to
the direct parameter of the ``run'' handler. So, your TOY 4 should be like this:
on run argv -- THIS
with timeout of 3600 seconds
tell application "Reminders"
set allRems to (properties of every reminder whose completed is false)
display dialog "Got " & (count of allRems) & " reminders"
end tell
end timeout
end run -- and THIS
I tried this script in the Terminal, using following command, and it successfully asked for access to Reminders, and worked after access granting. Note quotes as well:
osascript '/Users/123/Desktop/synchRemindersTest.scpt' 'output.json' 'Reminders' 'ToDo'
I did not figure out exactly what was causing the issues, but I repeatedly tried the same exact code with varying results/behaviors, apparently depending on various circumstances. Here are my observations.
Using any of the toy examples, there were 2 running behaviors that seemed to change:
runtime (fastest I could get was near half a minute, but the same code could take over 10 minutes in certain cases - I control-c'd them, so I don't know how long they'd have run)
tccd and other errors in the console (having to do with Apple's mechanism for "transparency, consent, & control" - i.e. the thing that makes those access request popups happen)
I tried running the toy examples above in the following ways:
From Script Editor
Via osascript from the command line
Rewritten as Javascript for Automation (aka "JXA") (from script editor)
As an app, double-clicked
As an app opened from the command line
And I ran those various methods under the following various circumstances (where possible):
Immediately after unlocking the screen
With the Reminders App open on the current desktop
With the Reminders App open off the current desktop
Without manually interacting with the Reminders GUI prior to running
With manually interacting with the Reminders GUI prior to running
With including an applescript instruction to show a list in the Reminders GUI
Without including an applescript instruction to show a list in the Reminders GUI
And there's one other important factor to take into account:
Reminders database size
Apple doesn't actually ever delete anything from the reminders database. I currently have 9,604 completed reminders and 193 incomplete reminders. While exploring this issue, I discovered reminders over a decade old in my reminders database.
I suspect that the issues have more to do with the size of the database than the tccd errors, as I found threads on the Apple Developers forum that describe those errors as mere log noise. I also found posts by developers who note that the ever growing size of the reminders database leads to growing performance issues, and noted that there's no way to really delete entries. Deleted entries are simply labeled as deleted.
I have found that there is no reliable running context that runs both fast and without errors under every circumstance (when you have a large Reminders database). All the ways of executing fail under certain circumstances. Some cases run faster than others, but none ever run in what I would consider a reasonable running time.
I tried code-signing an app version of the toy scripts, explicitly granting entitlements to the reminders data, but according to an app called Taccy, while I could retrieve those entitlements from the files to which they were applied, they did not prevent the tccd errors or make any of the cases run faster. I even tried code-signing a copy of the osascript executable, but apparently it only works for app bundles.
While I could see a difference in runtime under certain circumstances and could avoid tccd errors by doing things in a certain way in some circumstances (all seemingly requiring true manual actions), the runtimes were never significantly improved and errors/failures seemed unavoidable in cases where for example, the screen was locked.
So I concluded that given the size of my reminders database and the fact that I wanted to run this script with the screen locked (e.g. on a cron job), I had to abandon an AppleScript solution. It's impossible to do it predictably & reliably. (I had briefly explored a Siri Automation on an iOS device, but discovered the hoops to jump through to get it to run more than once a day were too annoying.)
So remembering that reminders were(/used to be) stored as ics files in the Library folder. I learned that with the Reminders update in iOS 13 & macOS Catalina, storage of reminders had moved to an sqlite database under ~/Library/Reminders/Container_v1/Stores.
I poked around in the database last night and started to figure things out. I googled some of what I found and found a single google hit to a github repo that had already worked the difficult sqlite stuff out. I ended up with a shell script that reliably retrieves all reminder data (nearly 10k records) in about 1 second!
I have yet to refine it to convert it to JSON and to additionally retrieve anything modified after a certain date, but what I have so far is sufficient to answer this question.
I wrote the shell script in the (unpopular) shell language of tcsh. Feel free to rewrite it in bash or start from the repo I found, which already is in bash (but doesn't retrieve all reminders data):
set REMINDERS_STORES="$HOME/Library/Reminders/Container_v1/Stores";
set SQL_GET_Z_ENT="SELECT Z_ENT FROM Z_PRIMARYKEY WHERE Z_NAME = 'REMCDList'";
foreach DBFILE ( "$REMINDERS_STORES"/Data-*-*.sqlite )
set DB="file:${DBFILE}?mode=ro"
set COUNT=`sqlite3 "$DB" "SELECT COUNT(*) FROM ZREMCDOBJECT WHERE Z_ENT = ($SQL_GET_Z_ENT) AND ZCKIDENTIFIER IS NOT NULL;"`
if ( "$COUNT" > 0 ) then
set REMINDERS_DB="$DB"
endif
end
set Z_ENT_LISTS=`sqlite3 "$REMINDERS_DB" "$SQL_GET_Z_ENT;"`
set YEARZERO=`date -j -f "%Y-%m-%d %H:%M:%S %z" "2001-01-01 0:0:0 +0000" "+%s"`
set NOW=`date "+%s"`
sqlite3 "$REMINDERS_DB" "SELECT strftime('%Y-%m-%dT%H:%M:%S',($YEARZERO + TASK.ZDUEDATE),'unixepoch') as dueDate, TASK.ZPRIORITY AS priority, TASK.ZTITLE1 AS title, LIST.ZNAME1 AS list, TASK.ZNOTES AS notes, TASK.ZCOMPLETED as completed, strftime('%Y-%m-%dT%H:%M:%S',($YEARZERO + TASK.ZCOMPLETIONDATE),'unixepoch') as completionDate, strftime('%Y-%m-%dT%H:%M:%S',($YEARZERO + TASK.ZCREATIONDATE),'unixepoch') as creationDate, TASK.ZDISPLAYDATEISALLDAY as isAllday, strftime('%Y-%m-%dT%H:%M:%S',($YEARZERO + TASK.ZDISPLAYDATEDATE),'unixepoch') as alldayDate, strftime('%Y-%m-%dT%H:%M:%S',($YEARZERO + TASK.ZLASTMODIFIEDDATE),'unixepoch') as modificationDate, TASK.ZFLAGGED as flagged FROM ZREMCDOBJECT TASK LEFT JOIN ZREMCDOBJECT LIST on TASK.ZLIST = LIST.Z_PK WHERE LIST.Z_ENT = $Z_ENT_LISTS AND LIST.ZMARKEDFORDELETION = 0 AND TASK.ZMARKEDFORDELETION = 0 ORDER BY CASE WHEN TASK.ZDUEDATE IS NULL THEN 1 ELSE 0 END, TASK.ZDUEDATE, TASK.ZPRIORITY;"
Here is an example of the output:
2011-11-01T18:30:00|0|Pay the rent|ToDo Home Recurring||1|2011-11-03T13:21:00|2017-09-18T16:59:00|0|2011-11-01T22:30:00|2020-01-04T20:40:00|0
2011-11-05T15:45:00|0|Feed meter|Reminders||1|2011-11-06T15:39:00|2017-09-18T16:59:00|0|2011-11-05T19:45:00|2020-01-04T20:36:00|0
Note, to get the dates in your time zone, as opposed to GMT(/UTC?), append 'localtime', e.g.:
strftime('%Y-%m-%dT%H:%M:%S',($YEARZERO + TASK.ZDUEDATE),'unixepoch', 'localtime')
I am fairly new to Prometheus alertmanager and had a doubt regarding firing alerts only during a particular period
I have a microservice which receives a file and does some processing on it, which is only invoked when it gets a message through a Kafka queue. The aforementioned is supposed to come every day between 5 am and 6 am(UTC time). The microservice has a metric which is incremented by 1 every time it receives a file. I want to raise an alert if it does not receive a file in the interval. I have created a query like this :
expr : sum(increase(metric_name[1m]) and on() hour(vector(time()))==5) < 1
for: 1h
My questions:-
1) Is it correct or is there a better way to do it
2) In case of no update, will it return 0 or "datapoints not found"
3) Is increase the correct function as it tends to give results in decimals due to extrapolation, but I understand if increase is 0, it will show 0
I can't really play around with scrape_intervals, which is set at 30s.
I have not run this expression but I expect it will cause an alert to fire at 06:00 only and then go off at 06:01. It is the only time the expression would hold true for one hour.
Answering your questions
It is correct if what you want is a single fire of alert (sending a mail by example) but then no longer firing. Even with that, the schedule is a bit tight and may get hurt by alertmanager delay causing the alert to be lost.
In case of no increase, you will get the expression will evaluate to 0. It will be empty when there is an update
Increase is the right function. It even takes into account reset of the counter.
Answering if there is a better way to do it.
Regarding your expression, you can have the same result, without for clause, with:
expr: increase(metric_name[1h])==0 and on() hour()==6 and on() minute()<1
It reads a : starting at 6am and for 1 minutes, if there was no increase of metric over the lasthour.
Alerting longer
If you want the alert to last longer (say for the day and you silence it when it is solved), you can use sub-queries;
expr: increase((metric and on() hour()==5)[18h:])==0 and on() hour()>5
It reads as : starting at 6am (hour()>5), compute the increase over 5-6am for the next 18 hours. If you like having a pending, you can drop the trailing on() hour()>5 and use a for: 1h clause.
If you want to alert until a file is submitted and thus detect a resolution, simply transform the expression to evaluate the increase until now:
expr: increase((metric and on() hour()>5)[18h:])==0 and on() hour()>5
I am using the wxProgressdialog to show time between switching ports and time between taking measurements. I am running this test for over 24 hours (repeating the same thing over and over while recording the data). Therro that appears during hour 7 is:
Traceback (most recent call last):
File "C:\Users\localuser\Desktop\Thermal\Cheyenne_Antenna_Cal_PDA_Thermal_Test.py", line 2117, in take_measurements_at_interval
self.take_measurement(self)
File "C:\Users\localuser\Desktop\Thermal\Cheyenne_Antenna_Cal_PDA_Thermal_Test.py", line 2185, in take_measurement
self.Measure_Plot(self)
File "C:\Users\localuser\Desktop\Thermal\Cheyenne_Antenna_Cal_PDA_Thermal_Test.py", line 2231, in Measure_Plot
style=wx.PD_AUTO_HIDE | wx.PD_ELAPSED_TIME | wx.PD_REMAINING_TIME)
File "C:\Python27\lib\site-packages\wx-2.8-msw-unicode\wx_windows.py", line 2951, in init
windows.ProgressDialog_swiginit(self,windows.new_ProgressDialog(*args, **kwargs))
wx._core.PyAssertionError: C++ assertion "wxAssertFailure" failed at ....\src\msw\control.cpp(159) in wxControl::MSWCreateControl(): CreateWindowEx("STATIC", flags=52000100, ex=00000000) failed
Here is the code that is being used to 'delay time'
#Giving Time for switch to toggle next port
progressMax = 5
dialog = wx.ProgressDialog("A progress box", "Time to switch", progressMax,
style=wx.PD_AUTO_HIDE | wx.PD_ELAPSED_TIME | wx.PD_REMAINING_TIME)
keepGoing = True
count = 0
while keepGoing and count < progressMax:
count = count + 1
wx.Sleep(1)
keepGoing = dialog.Update(count)
dialog.Destroy()
The code pauses 5 seconds to allow switch hardware and PNA to be steady before data is recorded. All of this is happening in a 'For' loop for a period of time. If anyone needs more information I will be happy to proved.
If the window creation fails after running for a long time, chances are you simply run out of windows, which are still a very limited resource under Microsoft Windows (the exact limit depends on the Windows version, but could be as log as 16,384).
This could happen if you never return to the main event loop during all this time because the top level windows will only be really destroyed (and not just hidden) once you get back to it.
I have a table of eBay itemid, and for each id I want to apply a reviseitem call, but from the second call I get the following error:
You have exceeded your maximum call limit of 3000 for 5 seconds. Try back after 5 seconds.
NB: I have just 4 calls.
How can I fix this problem?
ebay count the calls per second per unique IP's. So please make sure your all calls from your application must be less than 3000 per 5 seconds. hope this would help.
I have just finished an eBay project and this error can be misleading. eBay allow a certain amount of calla a day and if you exceed that amount in one 24 hour period you can get this error. You can get this amount increased by completing an Application Check form http://go.developer.ebay.com/developers/ebay/forums-support/certification
The eBay Trading API, to which your ReviseItem call belongs, allows up to 5000 calls per 24 hour period for all applications, and up to 1.5M calls / 24hrs for "Compatible Applications", i.e. applications that have undergone a vetting process called "Compatible Application Check". More details here: https://go.developer.ebay.com/developers/ebay/ebay-api-call-limits
However, that's just the generic, "Aggregate" call limit. There are different limits for specific calls, some of which are more liberal (AddItem: 100.000 / day) and others of which are more strict (SetApplication: 50 / day) than that. Additionally, there are hourly and periodic limits.
You can find out any application's applicable limits by executing the GetApiAccessRules call:
<GetApiAccessRulesResponse xmlns="urn:ebay:apis:eBLBaseComponents">
<Timestamp>2014-12-02T13:25:43.235Z</Timestamp>
<Ack>Success</Ack>
<Version>889</Version>
<Build>E889_CORE_API6_17053919_R1</Build>
<ApiAccessRule>
<CallName>ApplicationAggregate</CallName>
<CountsTowardAggregate>true</CountsTowardAggregate>
<DailyHardLimit>5000</DailyHardLimit>
<DailySoftLimit>5000</DailySoftLimit>
<DailyUsage>10</DailyUsage>
<HourlyHardLimit>6000</HourlyHardLimit>
<HourlySoftLimit>6000</HourlySoftLimit>
<HourlyUsage>0</HourlyUsage>
<Period>-1</Period>
<PeriodicHardLimit>10000</PeriodicHardLimit>
<PeriodicSoftLimit>10000</PeriodicSoftLimit>
<PeriodicUsage>0</PeriodicUsage>
<PeriodicStartDate>2006-02-14T07:00:00.000Z</PeriodicStartDate>
<ModTime>2014-01-20T11:20:44.000Z</ModTime>
<RuleCurrentStatus>NotSet</RuleCurrentStatus>
<RuleStatus>RuleOn</RuleStatus>
</ApiAccessRule>
<ApiAccessRule>
<CallName>AddItem</CallName>
<CountsTowardAggregate>false</CountsTowardAggregate>
<DailyHardLimit>100000</DailyHardLimit>
<DailySoftLimit>100000</DailySoftLimit>
<DailyUsage>0</DailyUsage>
<HourlyHardLimit>100000</HourlyHardLimit>
<HourlySoftLimit>100000</HourlySoftLimit>
<HourlyUsage>0</HourlyUsage>
<Period>-1</Period>
<PeriodicHardLimit>0</PeriodicHardLimit>
<PeriodicSoftLimit>0</PeriodicSoftLimit>
<PeriodicUsage>0</PeriodicUsage>
<ModTime>2014-01-20T11:20:44.000Z</ModTime>
<RuleCurrentStatus>NotSet</RuleCurrentStatus>
<RuleStatus>RuleOn</RuleStatus>
</ApiAccessRule>
You can try that out four your own application by pasting an AuthToken for your application into the form at https://ebay-sdk.intradesys.com/s/9a1158154dfa42caddbd0694a4e9bdc8 and then press "Execute call".
HTH.