There seems to be a silent fail when trying to stream tracks from an account.
Example:
API Gee console:
https://api.soundcloud.com/tracks/#####.json?consumer_key=###
Response: 200
Streamable: true
API Console Stream URL:
https://api.soundcloud.com/tracks/#####/stream?consumer_key=###
404 not found - (Blank white page no error in browser)
Track set to public and API streamable - All tracks on account, which were streaming as normal until the end of last week.
The consumer key works for tracks by other users, so it could be linked to this account directly?
For those coming here for an answer to this problem, it is a known bug when a song reports streamable: true yet results in a blank white page in browser when trying to stream. The bug is in the streamable boolean being false.
Email response from SoundCloud on this issue:
The developers have let me know that the problems you are having is
due to issues with RTMP.
Currently certain content on SoundCloud is using a secure streaming
method called RTMP.
To explain RTMP, even if a track is set to public and streamable by
the artist, if the artist is under a major label, this label can
further control those streaming permissions. So, it looks like it
should stream correctly, however it doesn't.
This particular bug that you have highlighted is more complicated than
originally thought, and as only a handful of tracks are affected we
unfortunately don't have the resources to dedicate a team entirely to
this project as of right now.
So unfortunately you'll just have to deal with/work around this issue.
I've noticed that i get blank page for stream url of tracks which are in "wav" format:
<original-format>wav</original-format>
other formats were working fine.
Not sure what track you're trying to stream. Some tracks are set by the artist to not be streamed.
You got the format for the url correct. Try this url with your own consumer key:
http://api.soundcloud.com/tracks/32476280/stream?consumer_key=[###]
After being in touch with the support team at SoundCloud, they provided the following:
The problems you are having is due to the content and rights holders.
To explain, profile admins have the ability to change settings as they
like, so if the tracks have stopped playing, it's likely that they
have disabled apps on the track or content. This means that the rights
holders, that own all of this content, have turned this setting off,
and we don't have control over it or the ability to enable it again.
They managed to get my "API permissions extended" because the rights holders own the SoundCloud account in question. It seems there was just a mistake somewhere along the way with denying streaming.
You'll need to log an issue with SoundCloud support if you have a similar problem.
Related
I have downloaded the UPS Rate API zip file and the JSON documentation uses https://wwwcie.ups.com/ship/{version}/rating{requestoption} for the POST request to get information.
Watching a youtube video from 2018 however shows a different set of documentation and a different POST URL (https://wwwcie.ups.com/rest/Rate)
I can get a response from the URL on the outdated documentation and have found a few other articles/questions that are using the older URL even recently, but all I ever get from the URL in the current documentation is an Invalid Access License Number error even though the number is correct.
Can anyone shed some light on what the difference is between these two are?
Surely one of those urls is the shipping api, the other is rate?
URLS change depending on format JSON or XML or whatever.
This has been asked a few times over the past couple of years but as Facebook tells me "Facebook engineers actively participate on StackOverflow.." So I'm hoping get get some joy here.
We have uploaded a video to youtube, passed it round and made sure we are happy with it, made it public and tried to change the title from 'xxx - final' to the actual title. However, Facebook shares are showing the old prerelease title but not the actual title, leading to much confusion amongst our subscribers and those trying to share the video. I should add the time between clicking the 'public' button to updating the title was a matter of minutes and seconds.
I have run it through the Facebook debugger and the scraper can see the changes but the problem persists along with the following debugger message:
"Attempted Frozen Title Change It appears that you are trying to change the property og:title from xxx to xxx. If so, you are not allowed to for this object because too many actions have been published against it."
This is obviously a real problem for us. Has anyone come up with a definitive solution or course of action? We can't simply delete the video because its for a band and there have been numerous post to not only Facebook but fan forums and elsewhere already and deleting and re-uploading the video would require an alternative url.
Many thanks
I managed to talk to a FB developer about this. Is seems that its a protective measure to stop click baiting, fake links and so on. His advice was make sure you upload the file as you want to see it when it goes live - ie. Don't use 'video 4.. final version' or some similar 'temporary' title because as soon as people start to view click or comment it becomes locked.
The engineer I spoke to was kind enough to unfreeze the video so all was well in the end, but looking at the comments of others who have had the same problem I was pretty lucky as it was a long standing Youtube account with 100,000's views and hundreds of links pointing to it meaning they were comfortable that I wasn't 'trying it on'.
So the bottom line is: if you want to upload a video and share it with your Facebook account, make sure the you have set the titles, tags and any metadata on the video immediately and before you paste to, or, share on youtube or there is a strong possibility that even though you can update that info on Youtube, Facebook won't recognise the changes and instead use the information it has in its database when the video was first scraped.
There are some old posts related to this topic but the API has since changed, so I wanted to ask again. Is there any way to remove photo tags with the Facebook API?
I saw this documentation about deleting photo tags with the graph API.
https://developers.facebook.com/docs/reference/api/photo/#tags
You can delete a tag for a particular user in the photo by issuing a HTTP DELETE request to /PHOTO_ID/tags/USER_ID or PHOTO_ID/tags?to=USER_ID.
Deleting a tag on a photo requires the publish_stream permission and supports the following parameters.
Parameter Description Type Required
to USER_ID of the User to tag; can also be string yes
provided in URL path (see above).
If the deletion is successful, you get the following return.
Description Type
If the deletion succeeded boolean
It did not work when I tried it. Instead, I always get the following error:
{
"error": {
"message": "(#3) Application does not have the capability to make this API call.",
"type": "OAuthException",
"code": 3
}
}
I submitted a bug report to Facebook and they seemed to acknowledge a bug by putting it into "triaged" status. Then a few weeks later, although several other developers had subscribed to the bug report, they closed the case with this explanation:
We are prioritizing bugs based on impact to the developer community. As this bug report has not received much attention from other developers, we are closing it so as to better focus on the top issues. There is a good chance your issue is due to an implementation problem in which case you can try to find help on Stack Overflow.
The bug report is here: https://developers.facebook.com/bugs/122135101317762
Can anyone help me figure out how to untag via the API? My app is currently written as a Web app, not as a mobile one.
Thank you in advance for any help on this.
Update: As Christopher Blizzard explains in the accepted answer, this isn't in fact a bug, but intentional behaviour that was previously badly documented.
Before this was known, back when this answer was first posted, I investigated a little to try and figure out if there was any way around this restriction. The answer is no. I've left the detail of my findings below in case they are of interest to anybody in the future, but Christopher Blizzard's input makes most of this obsolete.
I'm reasonably confident that the answer is no, there's no way at all. I've exhausted all possible lines of investigation I can think of, and come up blank. Let me list my findings:
1) The bug affects both ways of deleting photo tags listed in the documentation.
Sending a delete request to https://graph.facebook.com/PHOTO_ID/tags/USER_ID/ and sending one to https://graph.facebook.com/PHOTO_ID/tags?to=USER_ID should both work, according to the documentation. However, in reality, both approaches fail with the following error, as you've already observed:
{
"error": {
"message": "(#3) Application does not have the capability to make this API call.",
"type": "OAuthException",
"code": 3
}
}
2) It's got nothing to do with your app's permissions
Using Graph Explorer you can easily test this stuff out using an access token that grants you all possible permissions, and deleting tags still fails.
3) It's got nothing to do with the user's privacy settings
I tried creating a new user on Facebook and setting every single privacy setting in the settings menu to the most lenient option available. It made no difference.
4) It's not to do with the photo's owner or how the original tag was created
Even when the person whose access token you're using owns the photo that the tag is on and created the tag themselves, you still get the same error when trying to delete the tag. This applies whether they created the photo and tag through the normal Facebook user interface, or with your app through the Graph API.
5) There's no workaround using APIs other than Graph
FQL only allows data retrieval, not insertion, modification or deletion. Open Graph has no methods relating to photos or photo tags. The deprecated REST API - which is still functional, but which Facebook instructs us not to use, and whose documentation has been taken down - has functioning methods for getting and adding tags, but none for deleting them, as you can see in a a cached version of the documentation, via the Wayback Machine.
6) There doesn't seem to be any way to delete a tag using POST requests.
You can change the location of an existing tag, but that's it. Specifying an invalid location throws an error and doesn't affect the existing tag. Specifying the to field twice in a post request to try and change the target of a tag throws an error and has no effect.
7) Others have tried to solve the same problem before, and they have not succeeded.
I haven't found many posts about this issue, but there are these two, neither of which are helpful:
Delete photo tag from Graph API
http://queforum.com/facebook-applications/78655-facebook-untag-user-photo-via-facebook-graph-api.html
After testing all the points above, I'm out of ideas. Of course, there's no way I can say with certainty that this is impossible - we don't know what's going on on Facebook's back end or why the bug exists. I think these tests represent a pretty thorough examination of the problem, though, and they haven't revealed any solution.
I just updated the documentation on developers.facebook.com, but the short version is that the delete tag API is whitelisted only for certain apps.
I'm attempting to set up an app for a small set of known users, all of whom have a sub "page", "account" or whatever the terminology du jour is. The main goal of the app is to publish photos to these sub-accounts in an automated fashion on their behalf.
The crux of the issue seems to be that while I can ask for "manage_pages" to manage the user's sub-accounts and for "publish_stream" which allows me to upload photos to the user's root stream I can't upload photos to a subaccount stream.
I've been able to do a status update on the sub-account stream (text only), but every time I try to upload a photo (via curl, commandline-style), I get various errors depending on how I try to do it:
http://graph.facebook.com/albumid/photos -> Error #324 requires upload file
http://graph.facebook.com/albumid -> Error #200 application does not have the capability to make this API call.
http://graph.facebook.com/subaccount_id/feed - > Error #100 Source URL is not properly formatted
http://graph.facebook.com/subaccount_id/photos -> Error #324 requires upload file
I've stabbed around in the dark like this for about 4 hours with no luck and am beginning to wonder: Is posting a photo to a user's sub-account stream even possible? If so, how?
(BTW, I have tried doing a text status update with a photo URL -- attempting to circumvent the whole uploading part -- and that doesn't help. The url of the photo appears in the post, but does not show the photo. I'm open to any suggestion that shows photos in a subaccount stream.)
Only about 5 minutes after posting this, I kind of, sort of found a solution:
First, upload the image to your own web server, s3 bucket, or other location.
Second, use http://graph.facebook.com/subaccount_id/feed with source=http://www.thenewlocationofyourimage.com/image.jpg.
The image shows up in the page stream, albeit as a small thumbnail. Better than nothing, though. If you have better information, PLEASE let me know. Thanks!
About a month ago YouTube decided to get rid of it's "tags" from the frontend of their website:
http://youtubecreator.blogspot.com/2012/08/tags-removed-from-video-watch-pages.html
Which also in turn left media:keywords blank through any API feed request as read here:
http://apiblog.youtube.com/2012/08/video-tags-just-for-uploaders.html
The nice thing was for another month or so (until a few days ago) you could still access a video's "tags" or "keywords" through the API by looping through the category term(s)
It seems YouTube has taken that away also and it now only displays ONE category term for each API feed...and most of the time they are the basic YouTube categories like "Music" or "People" etc.
My questions to the YouTube development team is why was this taken away from the API (I understand taking it away from the frontend of the website) and will it ever return in any form to the API?
In the original Creators blog post you guys stated:
"Tags remain an important way to organize and help others find your videos. We strongly encourage you to continue tagging videos -- this will help increase your audience by improving the discoverability of your content."
So if Tags are still important and still utilized for search results...why in the world are they not available through the API anymore?
Any help and/or info would be greatly appreciated as this has completely destroyed the functionality of MANY of my sites! Thank you.
It appears they've made them private and you must use an authorized API request with adequate channel privileges to access them now. This really sucks since I've used them for filtering videos from a channel on a site and making authorized connections to the API via PHP has been complicated for me to get working correctly.
And the fact that this added complication is ONLY for keywords seems a bit ridiculous, but I don't guess the Youtube API team cares.
Unless a WHOLE lot of people complain about it, I doubt they'll add this back as a public.
I just added
Update: This change also applies to <category
scheme="http://gdata.youtube.com/schemas/2007/keywords.cat"> tags,
which were not mentioned in the original announcement.
to the announcement blog post. <category> tags should have been removed for the same reason <media:keywords> was removed, but due to an oversight they were left in unauthenticated API responses for a few weeks. There are no plans to add back keyword information via either metadata field.
If your goal is to have some semantics in the video, Freebase Topics can help. You can for instance do a JSONp call
<script src="https://www.googleapis.com/freebase/v1/topic${item}?filter=/type/object/name&callback=putFBname"></script>
with a small javascript function
<script>
function putFBname(respuesta){
span=document.getElementById(respuesta["id"]);
span.innerHTML=" "+respuesta["property"]["/type/object/name"]["values"][0]["text"];
}
</script>
to get the name of the topic.
Freebase topics come in the API v3.