Chrome extension publishing delays - google-chrome-extension

I published a new version of my Chrome extension on the 29th of October, and the publishing process is still pending since (17 days). I tried to cancel and republish, I even wrote to the Google dev team, but nothing changed.
Most of the time, publishing takes a few hours only, but on a few occasions I had to wait between 3 and 10 days to get the update approved.
But more than 17 days now seems absolutely crazy. I don't know how I can provide a reliable experience for my users with such random and long delays (what if there's a bug I need to fix?).
Does anyone know why this process takes sometimes long? Is there anything I can do to change that? How do other extensions handle these delays?

Related

Bot scheduled messages using Cron have multiple-minute delay

I've been learning how to make Discord bots recently and have been experimenting with scheduled messages. Currently, I have 8 or so messages scheduled to send throughout the week. Some send at a certain time every single day, while some send at a specific time only on the weekends, etc.
Every few weeks or so, however, the messages start sending one minute later than they're supposed to. It started with just sending one minute late, so I adjusted the time in the job to one minute later, but the delay just keeps getting worse. Now the messages are sending 7 minutes later than they're supposed to according to the time I originally set in the job.
I'm very much an amateur, and I'm not sure what might be causing this.
The only thing I have been able to come up with to remedy the problem is adjusting the time in the job, but that's definitely not an ideal solution. It works for a little while, but then the message just delays even more.
The issue still persists even after I've reset the bot, refreshed the js files, etc. as I've been working on other bot functions.
Is there a way to reset those Cron tasks specifically, so they're running on time again. Is the reason just because I have other stuff going on in the command file where those jobs are started? If so, how could I remedy that besides moving it to a separate file?

Classic ASP: response time periodically slows down extremely

I have a problem with a bunch (around 50) of classic ASP-Sites on Win2012R2 with Access-Databases, which drives us crazy.
All asp-pages of all sites on this server run smoothly for around 45 seconds, after that period they (all) completely stop responding to any click for 15 to 20 seconds, then this delay disappears again for the next 45 seconds like it never existed before, it re-appears again - and so on. This effect started out of nothing a few weeks ago, after several months without any problems.
Static HTML-pages are not affected, and it seems, even asp-pages without connecting to their database run fine. We, therefore, tried testing to convert from Access to SQLExpress, but this didn't change anything - even the converted site was affected in the same way (so it seems not to be Access).
We then tried to stop all sites in IIS and re-activating just one single site with very few visitors to see if it only appears, when many requests are sent to the server. But the effect still showed up, even after Restarting IIS and even after restarting the whole machine with just one website activated in IIS. It seems to be completely independent from the number of effects, just like the server (rather: the asp-engine of IIS) being busy with itself in a periodical pattern.
What we can see in performace monitor (see screenshot): while requests/sec goes down to 0 at some moment, when the effect starts, the number of requests executed continuosly accumultes from a normal level (which looks "logical" to me, but only describes the effect, not justifies, where it comes from). A few seconds before the effect vanishes, request/sec again grow and these counters revert to normal values.
We had a similar problem a year ago on a Windows 2008-Server, where the sites ran without any problems for several years and then it started out of nothing. After testing some of the sites on a server of another hoster, we found out, the problems didn't appear on his server with Windows 2012 R2 (and still don't for a full year, while hosting 3 of our sites there). At another hosters virtual Windows 2012R2-Server we have another single site hosted with more traffic than most of our others and even there the problem didn't appear since a full year now. So we our hoster switched over to WinServer2012R2 and - bingo - all the problems were gone. All sites performed like a charm again from that moment on without changing anything but the OS.
We then stopped investigating the issue, thinking the problem relates to the OS. But around 9 months later, it re-appeared and after hours and hours of investigating we have no idea, what to search for and what to do (beside of moving all our sites to the other hosters server, which isn't a real solution to the problem and we cannot guarantee, the effect will not re-appear on this machine sometimes in the future).
I definitively found a solution by myself, but in a totally random way. After weeks of searching for a solution to the problem, I worked on cleaning up the server's hard disk and deleted all files in Windows/temp-folder (> 18.000 files!). And since this moment (4 days ago), the described response lag never showed up any more! But a small bunch of new .tmp-files were created in the folder.
My theory is: maybe every time a user visits one of the websites (which opens connections to its Access database, causing a .ldb-file in the database folder), a randomly(?) named .tmp-file (like: jet12f0.tmp) is created in Windows/temp folder in parallel. These files are "normally" deleted again, as database connection closes and the .ldb disappears. Maybe some of the connections are not closed correctly, therefore the corresponding .tmp-file in the Windows/temp folder resides there as an "orphan", literally forever. As time goes by, the folder fills up with these orphaned files. And then it comes, that a new .tmp-file should be generated, but with a name of a still existing "orphaned" .tmp-file. This now causes the server to stop all actions, because it is not possible to establish the new file, named like an existing. After 15 to 20 seconds the conflict is solved by some mechanism (unknown to me) and all runs perfect again, until the next conflict arises around 45 seconds later. And so on...
I must assume: this is only a "amateur" theory, I'm not a server "Guru".
Cleaning up this temp-folder from time to time seems to prevent the server from getting into this situation, because there are no file/naming conflicts.
I agree: The real solution would be finding the problem in the code (if there is one), but we can live with that situation, comparing the effort to find the problem with just cleaning up the temp-folder once in a month or so ;-)

How to avoid a web app timout whilst data-crunching?

Now my Python web app spends so much time data-crunching that PythonAnywhere assumes that the app has crashed and times out. (>5 mins = timeout)
My plan is (ultimately) to deliver the output to users by email, so they dont have to wait around anyway. ("Please check your email in 10 mins for your report").
I thought about doing a screen "refresh" periodically during the data-crunching to keep pythonanywhere happy - BUT if users close the browser then this isnt going to work.
How can I avoid a timeout and keep the app running for 10-15 mins without a browser?
Joe
PythonAnywhere dev here -- I think we've already discussed this over email, but I'll post what I said here just in case it's useful for other people.
A good option for stuff that takes a long time to run is to refactor it into a script that you can run periodically, and then schedule that on the "Tasks" tab. If you have a paid account, you can schedule up to 20 hourly tasks (we can bump that up if you need more), so to make the script run every (say) ten minutes, you could schedule it at 2 past the hour, 12 past the hour, and so on. If you need the script to process data that comes from the user via your website, you could make your view write something to the database with the details of what needs doing, then the scheduled task could pick that up, process it, and put the results in the DB for the website to pick up.
We've got a help page with a bit more information here.

"General permanent error" during libspotify search

I've recently started programming in C on my Raspberry Pi. I have downloaded libspotify (I have the correct version), and have managed it pretty well.
Just recently (~2 hours ago (around 18:00 30/12/2013)), libspotify started to return SP_ERROR_OTHER_PERMANENT when checking for a search error in the search_complete_cb callback.
Before the error started occuring, I have built and started the program quite a few times (and thus, logging in many times, during only a short period of time), and to test my 'Search' feature, I have used the same query every time. Then, without making any changes to my program, suddenly there were no results returned after calling sp_search_create.
I am worried that the developer account has been somehow suspended for either repeatedly logging in, or because it seemed weird to the spotify crew that I would search for the same query all the time. I don't really know what the problem is caused by. There are no emails or warnings sent to the address connected to the account. The problem has lasted for a while now, so it seems like it's not going away at first.
Additional details
log_message tells me there is a ChannelError(4, 0, search). I have also seen ChannelError(5, 0, search), but only once.
I can still play music from the official Spotify desktop client for Windows.
I have an earlier version of the program, before I rewrote it to get a bit more structure, that works. The same API key and same credentials are used in both programs, so that excludes a ban. The rewrite does log in, but no results are returned from searching. In the old version, I get a lot of results. All working. I have rebooted the Raspberry Pi several times, but that doesn't seem to help.
If you need any code or other information, I'll be happy to share. Just point out what's needed, because the code is split over a lot of files.
Well, if your old one is working then the problem will be in your rewrite. Don't pay too much notice to the error messages, they're pretty much par for the course, and can be triggered by something as benign as a cache miss. Unless you're actually getting an error callback somewhere, the log messages are meaningless.
As for your problem, I can't really make any guesses without seeing your code. One thing to check and is the most common course of a permanent error is to make sure you're actually logged in. The login process is asynchronous, and any functionality that requires you to be logged in (searching is one of them) will fail before login is completed.

WP8 ScheduledActionService - alarm delay

I'm getting a lot of reports about a problem with delayed notifications from people using my timer app on windows phone 8.
http://www.windowsphone.com/en-us/store/app/timer/38ac6043-0d3e-471a-9527-a20d1ef8521b
There was always the problem that Alarms added to the ScheduledActionService aren't very accurate. I fixed the problem when the app is running by adding and removing a dummy alarm shortly after the real alarm counted to 0. This "woke up" the ScheduledActionService, it checked for expired alarms and showed the notification. This behaviour changed with WP8.
My little hack doesn't work any more and a lot of people seems to be quiet frustrated about it. I also got feedback that sometimes the alarms don't work under the lockscreen at all. Sadly I can only reproduce the first problem on the emulator. Has anyone experienced similar behaviour?
Is there any other possibility to tell the ScheduledActionService to check it's alarms?
Is it possible to hide my app in the store on WP8 devices up to the time when I corrected this behaviour?
regards,
Christian
I ran into a similar problem. I created a basic voice enabled timer app. The problem I had was if someone sets the alarm to go off in 20 seconds and I create that scheduled action well its not going to work for one minute.
"Alarms and Reminders are accurate only within a range of one minute. In other words, the notification can be launched up to one minute after it was scheduled." -msdn
I know you know this but I thought I would include it for others reading. I ended up initially creating all alarms via a timer in code and if the user exits the app only then do I create a scheduled action. If the user tries to close the app and there is less than one minute remaining I show a message box I don't remember the exact warning but its along the lines of the phone cannot show the alarm for one minute after exiting the application.
Maybe you could split the options up for the user?
an accurate timer that only works when the app is open and you can control in code down to the second, and a more generic timer that works outside of the app that would only allow one minute increments.

Resources