Including &bucket=terms is causing error / incomplete response - echonest

This only started happening today, but if I include the "&bucket=terms" in a request, it leaves out all of the other details.
No terms - contains all other information
http://developer.echonest.com/api/v4/artist/search?api_key=__&format=json&name=brand%20new&results=1&bucket=familiarity&bucket=familiarity&bucket=hotttnesss&bucket=id:spotify&bucket=artist_location&bucket=years_active
Has terms - only returns id and name
http://developer.echonest.com/api/v4/artist/search?api_key=__&format=json&name=brand%20new&results=1&bucket=familiarity&bucket=familiarity&bucket=hotttnesss&bucket=id:spotify&bucket=artist_location&bucket=years_active&bucket=terms

These two are not working either. I noticed it this weekend. I didn't find any info about 'disabling' moods or styles in their API.
http://developer.echonest.com/api/v4/artist/list_terms?api_key=API_KEY&format=json&type=mood
http://developer.echonest.com/api/v4/artist/list_terms?api_key=API_KEY&format=json&type=style

Related

Get Status of Driver Inside Visual Basic

I'm currently trying to detect which drivers appear as "not working" in visual basic.
This unknown device is a good example of what I'm trying to grab (notice how it has the flag DN_HAS_PROBLEM).
I've tried using searches such as:
Dim searcher As New ManagementObjectSearcher( "root\CIMV2", "SELECT * FROM Win32_SystemDriver")
And running a loop in the searcher.Get() through this documentation
However, none of these seem to return what I am looking for.
Would anyone happen to know how I can get the DN_ statuses within Visual Basic?
Thanks!
The Win32_SystemDriver class documentation lists these Status properties:
OK
Error
Degraded
Unknown
Pred Fail
Starting
Stopping
Service
Stressed
NonRecover
No Contact
Lost Comm
...whereas DN_HAS_PROBLEM comes from the CM_Get_DevNode_Status function, or perhaps also from other system calls.
There may not be a way to get that specific code from the API you're using, but perhaps the existing Status properties will suffice for your needs if you don't need to know more specific failure reasons.
If you do need to know that specific status, you'll have to call other APIs, like the one I called out.

Problems with GitHub rendering my README.rst incorrectly..?

I've got a GitHub repo/branch where I'm attempting to update the README.rst, but it's not formatting the way I expect when it comes to the bullet lists I'm including.
Everything seems ok except for my Usage section, in which I have the following:
*****
Usage
*****
- Open the template file that corresponds to the API call you'd like to make.
* Example: If we want to make a call to the RefundTransaction API we open up /templates/RefundTransaction.php
- You may leave the file here, or save this file to the location on your web server where you'd like this call to be made.
* I like to save the files to a separate location and keep the ones included with the library as empty templates.
* Note that you can also copy/paste the template code into your own file(s).
- Each template file includes PHP arrays for every parameter available to that particular API. Simply fill in the array parameters with your own dynamic (or static) data. This data may come from:
* Session Variables
* General Variables
* Database Recordsets
* Static Values
* Etc.
- When you run the file you will get a $PayPalResult array that consists of all the response parameters from PayPal, original request parameters sent to PayPal, and raw request/response info for troubleshooting.
* You may refer to the `PayPal API Reference Guide <https://developer.paypal.com/webapps/developer/docs/classic/api/>`_ for details about what response parameters you can expect to get back from any successful API request.
+ Example: When working with RefundTransaction, I can see that PayPal will return a REFUNDTRANSACTIONID, FEEREFUNDAMT, etc. As such, I know that those values will be included in $PayPalResult['REFUNDTRANSACTIONID'] and $PayPalResult['FEEREFUNDAMT'] respectively.
- If errors occur they will be available in $PayPalResult['ERRORS']
You may refer to this `overview video <http://www.angelleye.com/overview-of-php-class-library-for-paypal/>`_ of how to use the library,
and there are also samples provided in the /samples directory as well as blank templates ready to use under /templates.
You may `contact me directly <http://www.angelleye.com/contact-us/>`_ if you need additional help getting started. I offer 30 min of free training for using this library,
which is generally plenty to get you up-and-running.
For some reason, though, when you look at that on GitHub the first line of the bullet lists is coming up bold and italics and I have no idea why. Also, the sub-list where it shows Session Variables, General Variables, etc. is supposed to be all the same sub-list. I'm not sure why it's dropping into another sub when it sees General Variables.
Any information on what I've done wrong here would be greatly appreciated. Thanks!
Switch from .rst to .md and then use '#' for your headings.
## Usage
- Open the template file that corresponds to the API call you'd like to make.
* Example

TYPO3 : no updated newsletter with direct_mail and scheduler

This is my 1st question on this forum... So, please, be indulgent !
I'm using TYPO3 4.7.11 (PHP 5.3.3) with extension direct_mail 3.1.1 for the intranet site of a non-profit firm.
My problem (maybe connected to Bug #51583 : http://forge.typo3.org/issues/51583) is that, after numerous tests and attempts, it seems impossible to have an updated version of a page saved as draft for newsletter in an automatic scheduler driven way : the same newsletter is produced with the same informations that were already there on the day it was first created and saved.
The specific page used for newsletter includes a content element 'Menu/Sitemap' with 'Recently updated pages' as 'Menu type'. It has been saved as 'draft (for recurring sendings)' in Direct Mail.
The scheduler contains these 2 tasks with recurring type :
- Direct Mail: Create Mail from Draft (direct_mail)
- Direct Mail: Mailing Queue (direct_mail)
Note : the manual way is fully functional and the newsletter produced is really updated. Same with option "Testmail - Simple" !
So, my problem seems to be linked to the automatic scheduled mailing ! It looks as if the newsletter draft has turned into a freezed snapshot of a specific moment and that Typo3 is unable to update/recalculate this page when invoked in scheduler mode.
On the web, I saw reported problems that could be related like "When mails get sent via the scheduler the same subject is used for all sendings ( https://review.typo3.org/21313 )" and "Adding hooks when sending direct mails via scheduler ( forge.typo3.org/issues/48994 )", but these issues seem to be fixed with direct_mail 3.1.1 version.
I made these observations and, in my opinion, there is some relevancy :
1.There is no domain proposed in the 'Domain of internal links' drop-down list in 'Set default values for mail content fetching options' in Direct Mailer, and yet I have a single record in sys_domain table with a domain name (with no protocol and no final slash). Is there a reason why this record is not considered good, or isn't it the right table ? (uid=3, pid, tstamp, crdate, cruser_id, hidden, sorting, prepend_params and forced=0, redirectHttpStatusCode=301, domain_name=site.subdomain.domain, redirectTo=)
2.In the Typo 3 Log, I get this systematic error message for user _cli_scheduler#LIVE :
Core: Error handler (BE): PHP Warning: Invalid argument supplied for
foreach() in
...typo3conf/ext/direct_mail/Classes/Scheduler/MailFromDraft.php line
125.
The concerned part of MailFromDraft.php is this function : initializeHookObjects
...
/*
* Initializes hook objects for this class
*
* #return void
*/
function initializeHookObjects() {
foreach ($GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['direct_mail']['mailFromDraft'] as $hookObj) {
$hookObjectInstance = t3lib_div::getUserObj($hookObj);
if (is_object($hookObjectInstance) && ($hookObjectInstance instanceof x_directmail_Scheduler_MailFromDraftHook)) {
$this->hookObjects[] = $hookObjectInstance;
}
}
}
...
I'm not sure of understanding very clearly the origin and the use of the hook Object... (in spite of this interesting article by Robert Lemke : typo3.org/documentation/article/how-to-use-existing-hooks-in-your-own-extension/ )
3.Nothing like the apparently requested GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['direct_mail']['mailFromDraft'] seems to exist in TYPO3_CONF_VARS (Global configuration).
Can anybody give me an advice or a clue about what's going on and why I can't get a weekly updated newsletter with the scheduler ? I feel a bit confused !
Thanks in advance for any suggestion or solution (if a miracle is possible).
Greetings.
P-H SILLIAU
I've read about this issue before, but couldn't remember where.
Googling "direct_mail draft (for recurring sendings)" helped.
Try this bug: http://forge.typo3.org/issues/4421
User Markus says:
Things work fine, when you set a domain-record in your system and
select it in the direct_mail settings!
If you don't have a domain-record and specify it in the direct_mail
setup you're able to send normal newsletters, but if you try the
draft-functionality it won't work because the getUrlBase function in
class.tx_directmail_static.php returns an unsuable URL to the System
so it can't use the fetchHTML($file) and quits - therefore not
replacing the old draft contents created when starting the first time.
I don't really get why this works the first time you set up the draft
though....
So setting up the domain-record is a work-around that works.
I hope it does!
Probably, you will find more related topics.
Else, workarounds would be
re-considering the task. As it's a NPO intranet, maybe requirements are not that required suddenly, if asked again :-)
setting up a custom notification tool that only does that precise job.
To put an end to this problem, after many attempts (and informations gleaned from the internet), here is the solution we finally used in our specific case to make the newsletter work :
1st. We created a record in table sys_domain. This was a recurrent instruction in the manual and the forums, and it was IMHO legitimate.
Important : note that the redirectTo field had to remain empty, due to global malfunction of the site if filled (whatever we put in it like /, /var/www/sitename, ...)
2nd. All images, CSS, JS included in template had to be hardcoded (i.e. http ://site/fileamin/images/xxx.png for instance). If we didn't do that, the result would have been an abort in the production of the newletter : Not Found... Maybe, by digging a bit deeper, should we be able to find a parameter we forgot or neglected in some way to solve this issue...
3rd. In the newsletter template TS setup, we added these 2 parameters :
mod.web_modules.dmail.use_domain=[uid of sys-domain]
config.absRefPrefix = / (in order to get rid of PHP DOCUMENT_ROOT (or TYPO3_DOCUMENT_ROOT ?) otherwise wrongly present in all generated links.)
The result is now a well dynamically-generated newsletter, the date is OK, all links are correct and realUrl-compliant (no ../index.php?id=nnn) .... and you know what ?... We're happy ! :-)
Hope it will help !
Many thanks to everybody who answered (Markus, Urs...) or even thought of a possible solution...
P-H Silliau

Expected response code 200, got 400. Unable to convert document

In the last 2 weeks or so, I've suddenly started getting reports of users getting an error in our application saying "Expected response code 200, got 400. Unable to convert document." This is code that has been in place for years without any issue. We are using Zend Framework (GData) in conjunction with Google Docs (AuthSub).
We are logging the issue to a text file when it happens. When it gets logged, the user often tries multiple times (sometimes separated by a few seconds, other times separated by longer times) and it continues to fail. The code in question just creates a new Google document in the user's account and gives it a title (no body content).
Originally, I used this code:
// Create new document
$data = new Zend_Gdata_Docs_DocumentListEntry();
$data->setCategory(
array(new Zend_Gdata_App_Extension_Category(
"http://schemas.google.com/docs/2007#document",
"http://schemas.google.com/g/2005#kind"
)));
$data->setTitle(new Zend_Gdata_App_Extension_Title($title, null));
// Add document to your list
$test = $sharedocs->insertDocument($data, Zend_Gdata_Docs::DOCUMENTS_LIST_FEED_URI);
To experiment and see if there was an issue with that particular function, I tried creating a blank word doc and changing the code to:
$test = $sharedocs->uploadFile('/mypath/empty.doc', $title, null, Zend_Gdata_Docs::DOCUMENTS_LIST_FEED_URI);
However, I'm still seeing the "Unable to convert document" errors. They are relatively infrequent, and I am not able to reproduce the issue on my own computers here. The $title variable does not contain anything unusual (special characters, etc.).
This code was all working fine before -- is there a known issue with the Google Docs API right now? What else can I try?
NOTE: Please see my follow-up comments below, where I have identified the reproducible scenario in which this error occurs.
I had exactly the same problem, but I noticed that I could use the api to save a presentation if not a document... so, it is a terrible hack, but I try to save the document (works if the account has already been accessed)... if that fails, I save and delete a presentation and retry to save the document, which then works. Horrible, horrible, horrible hack

Sugar CRM SOAP API - Problems with Auto Incrementing Key and set_entry

I've tried the SugarCRM forums for this problem as well, but I was wondering if anyone here has run into a similar issue and would be willing to share the solution.
We are working with the SOAP API for Sugar CRM via the Sugar On Demand system and their appears to be a problem - which at the moment looks very much like a bug.
The Module we trying to work with is the case module. We are running the set_entry action on the case module. It worked the first time we did this, but now it refuses to allow us to enter any more modules. I've checked the log files and made sure that we are submitting anything in the case_number field to over ride this, but whenever we try to add a new case we get the following error showing up in the log:
Query Failed: INSERT into cases set id='bb53030e-0f2f-5787-f403-4dde57cde36e', name='New RMA Request Test', date_entered='2011-05-26 13:37:15', date_modified='2011-05-26 13:37:15', modified_user_id='b1256ced-011d-7c1a-e1f3-4d4004ea4e9a', created_by='b1256ced-011d-7c1a-e1f3-4d4004ea4e9a', description='fjdlkas', deleted='0', assigned_user_id=null, team_id=null, team_set_id='ded0fbb0-c5dc-74ee-0622-4d22eb653a80', type=null, status=null, priority=null, resolution=null, system_id=1, work_log=null, account_id=null: MySQL error 1062: Duplicate entry '2147483647' for key 2
This is a bit odd for a few reasons:
I've confirmed that the corresponding key is auto-incrementing.
I am not submitting that number anywhere.
The next auto-increment value when I check the setting in the Studio is actually 2147483648.
Can someone explain what I need to do with the SOAP API to stop it from overriding the auto-increment value on my table?
Edit: I get the same error if I try to add a case via the interface, so I suspect this could be a problem with the CRM configuration itself rather than a SOAP related issue like I originally thought.
I would try to increase the size of the case_number field from an int(11) to something bigger and see if that fixes the issue.