URL login credentials for "IP Webcam" not working upon load in Media Tile

Our current Knowledge Base for Media - Video Tiles is pretty slim, particularly considering the value and complexity of the Topic.

1. ActionTiles's currently implementation for Video streams or "stop-motion-video" time-refreshed snapshots is nearly identical to SmartTiles. That's good because the existing SmartTiles knowledge is nearly always applicable. Not so good is that the functionality is, admittedly, still pretty limited as of this time.
2. We think there are some incremental fixes and improvements we can discover and may implement relatively soon; other issues are much harder. Some may practically resolve themselves... Support for RTSP streams, for example, is supposedly built-into some of the latest browsers. We will experiment with this.
3. Your authentication / camera stream login issue is a sub-topic in itself. As we rank our feature requests, this may be a unit of work that we can isolate.

In the meantime, please refer to our evolving KB article, which, in turn, refers to helpful discussions on the SmartThings Community Forum and the "Things That Are Smart" Wiki.

You might find a workable solution from those links (or asking there for help...). There are some super helpful folks contributing in the ST Community!

• How do I use Media Tiles to view my Video Cameras?
  • http://www.smarttiles.click/help/#Video_Streams
  • https://community.smartthings.com/t/smarttiles-video-camera-compatibility/11633?u=tgauchat
• • http://thingsthataresmart.wiki/index.php?title=SmartTiles_Video_Camera_Support

I second this as well... One of the main features i was hoping to see in AT is integration with security cameras. Blue Iris is the most popular. but i am still unable to make things work with AT due to authentication.

You'll get no disagreement from me... ActionTiles needs better Video Support!

However, we first need to figure out what specific feed types / functions are most urgent to improve and balance that with the effort requirements and practicality. Being 100% browser based is tremendous for convenience, but makes "non-basic" media handling more than a little difficult.

Please be sure to watch for and allocate Topic Votes that really help us prioritize our efforts!

Thanks,

...Terry.

Hi Allen...

This must be a bug that occurs under certain particular circumstances, as I don't experience it with my simple Foscams. I'll test with IP Webcam sometime, but we're a bit busy at the moment.

Let's try to collect much more detail on the problem you are experiencing...

• Is this behavior the same on different browsers (tablet, phone, PC, Mac; OS version, browser version)?
• Have you tested with other cameras besides IP Webcam?
• Are the connections SSL (https://)?
• Any other environmental factors you think could be involved?

Thanks,

...Terry.

Thanks for the quick response.

• This is common in Chrome on both Android and Windows 10, as well as in Edge and IE on Windows 10. Chrome at least gives the option to right-click the image, open it in a new tab (which auto-authenticates), and then go back to the Panel which works when refreshed. Edge and IE do not offer a way to authenticate the images.
• Sorry, I have no other cameras to test.
• The Android cameras connect via http, is this the problem?
• I can't think of any other factors other than my ddns, but the direct URLs work fine on-site and off-site including overseas. The URL format was taken directly from iSpy's database and is in the format of http://username:password@domain.ddns.net:port/video (the path videofeed also works the same way).

bump.  Same issue with my IP cams.  Only way to keep the feed consistent is to disable AUTH for viewing.  Otherwise I have to authenticate the url in the browser then go back to the panel.

Please confirm and supply the same (or more!) details as Tamathumper's post (since we don't have a thousand cameras to test with, we're counting on threads like this to try to find common themes - noting that my old Foscam's work "fine", at least in the small variety of browsers that I have tested):

1. The exact camera model(s).
2. The type of stream.
3. The URL format used.
4. Cases where it works (if any) vs cases where it doesn't.
   1. browser and browsing hardware and OS
   2. http:// vs https://
   3. Local IP address, vs port forwarding, vs dynamic DNS
   4. desktop or home screen "app" (immersive mode) vs just another tab
5. Number of concurrent streams.
6. Output from browser's debugger console F12 (where available)
7. etc.

We are getting to the point (or past the point, frankly), where we need to just build a list of tested camera + browser combinations and let it slowly grow; along with a poll of which are the most popular cameras we should focus on attempting to "make work". For the latter list, a great majority of them will not have a quick solution in the current "browser-embedded" architecture; however, if we don't know which cameras are worth some effort, we don't even have a place to begin.

I strongly second this as my top priority.  My media-centric dashboards are filled with gray boxes until I click on every video feed and select "open in a new tab".  The new tab opens fine and shows the video feed, then I close the new tabs and go back to the dashboard and click "Refresh" and all of my feeds work after that (until restarting the browser or rebooting).

Hi Joel, 

• Please share a test Panel with a failed video feed(s) to Terry@ActionTiles.com 
• What is the camera brand & model?

Terry my beta panel is being shared with you. I have a D-Link 934L camera. As I had said it works in Safari and IOS Chrome, but not on my Macs using latest Chrome.

Thanks for reporting this, Joel. We will take a look.

Latest Chrome is too bleeding edge, some times. One of their updates broke tile sorting functionality at one time. We went through all release notes for Chrome, line by line until we found the culprit. Let's hope the new bug in Chrome does not affect other platforms.

Thanks for looking.

This is a dlink dcs-5222l.  HTTP stream.

http://user:pass@xx.y.zzz.aaa/video/mjpg.cgi?profileid=1

Immersive and regular.

It didn't matter if it was internal or external IP.  Only works if first authenticated via chrome, IE or edge.  It will then work for a while, then stop.  Perhaps it is placing a temp cookie or token that expires after some time.  If so, does AT manage cookies or tokens for web content rendered in a tile?

We currently do zero (or very, very miniscule) manipulation of the image stream; which, frankly, might be the key to some of the possible solutions).

• Using a desktop browser, you can "inspect" and see exactly what is inside the <img> tag in the video Tile.
• Desktop browser debuggers (Chrome, Firefox, IE, Edge...) also show information on exactly what cookies are received and store, though I am unaware if the details of the cookie can be examined, such as the expiration time.
• You could, for example, compare the cookies that are generated when viewing the image stream by itself, and when viewing the image stream inside ActionTiles (as well as viewing the stream from the My Media page).

In short: For streams of this sort where no plug-in is required to view the stream, some persistent analysis of browser debugger data should yield some clues.

I would presume, for example, that if authentication is failing right when you load the Panel for the very first time, the debugger's console tab ought to say something. And the other tabs with detailed network and resource listings can't be ignored.

Here is some console output when loading a test panel with only this webcam:

> Mixed Content: The page at 'https://app.actiontiles.com/panel/c46efab8-b7a4-49c6-b0c6-2bff8baddb6a' was loaded over HTTPS, but requested an insecure image 'http://viewer:viewer@75.8.100.124/video/mjpg.cgi?profileid=1'. This content should also be served over HTTPS.

> GET http://user:pass@xx.x.xxx.xxx/video/mjpg.cgi?profileid=1         401 (Unauthorized) mjpg.cgi?profileid=1:1

Here is the IMG inspection:

img st-img-refresh="" ng-src="http://user:pass@xx.x.xxx.xxx/video/mjpg.cgi?profileid=1" src="http://user:pass@xx.x.xxx.xxx/video/mjpg.cgi?profileid=1"

My webcam does not serve images/video over HTTPS, only HTTP.

When I load the webcam URL directly, here is the console output:

Resource interpreted as Document but transferred with MIME type multipart/x-mixed-replace: "http://xx.x.xxx.xxx/video/mjpg.cgi?profileid=1".

And IMG inspect:

img style="-webkit-user-select: none;" src="http://xx.x.xxx.xxx/video/mjpg.cgi?profileid=1"

I do notice a refresh after first GET, where I suspect it authenticates, then reloads without credentials?

When I reload the tileset, it works fine after this, and the 401 error is not displayed in the console.  However, there is the following in the console:

[Deprecation] Subresource requests whose URLs contain embedded credentials (e.g. `https://user:pass@host/`) are deprecated, and will be blocked in M59, around June 2017. See https://www.chromestatus.com/feature/5669008342777856 for more details.

Thanks for this super useful output, ChrisP!

Of course, this foreboding statement from Google Chrome is a real bummer and major concern:

[Deprecation] Subresource requests whose URLs contain embedded credentials (e.g. `https://user:pass@host/`) are deprecated, and will be blocked in M59, around June 2017.

Chrome is really beginning to get under my skin. Who the heck are they to block what our customers decide they want to do with their own Camera URLs?

Funny part is, that "bug" is uncontested in the feature link.  

This is not uncommon for Chrome development. They (Google devs) have broken (and sometimes revert and fix...) dozens of features with every release. Their lack of consideration for public input is astounding, considering the millions of millions of Chrome users. 😖

Just added another camera (IP Webcam on an android device) using the same authentication method, with the same results.  Trailing portion of the URL is a bit different, but everything up to that is the same as my dlink.

I'm guessing it is the same root cause... But it is a little more difficult to get at the browser debugger on Android. 😐

I'll try to sniff the HTTP traffic using Android IDE in debug mode to see what is coming into the webcam server on the device from AT.

Man, it is really frustrating that Google did this. Is there a way to at least replace the image with an error message (not requiring console use) to at least make the issue obvious to the average user? Maybe even link to a kb article/forum post of your own on this? 

Well, they haven't broke it yet.  The issue here is repeatable in any browser.

I'm not sure what your comment is saying, ChrisP...?

I have heard that Firefox also blocks this format of URL. What browsers have you tested, and what specific issue is repeatable?

i am using hikvision cameras, i had to use https and enable https on some of my cameras in order for this to work. i am passing username and password in the url

I can report that Chrome doesn't work with my hikvisions but does with Safari......

Safari is a very unique beast... I remember the very short period when they offered a Windows version!

Plaintext credentials for embedded "basic http authentication" should be an option for users. If anyone happens to find an easy workaround, please let us know.

I can now confirm that it's broken entirely.  Opening the image in another tab still works, but no amount of refreshes will make the camera stream appear in ActionTiles (where, I assume, it would be considered a subresource).  Chrome version 59.0.3071.115.

Hi there,

How is your setup working at this moment? The media loading logic has been changed after you posted this comment.

Beta and Production have the same code right now...

Still well and truly broken. :(

Allen, I presume this has never worked for you? So, the latest update had no effect on this, correct?

It worked as originally outlined prior to Chrome 59 - video streams were broken when I opened an ActionTiles panel, but if I opened the streams in a new tab that would "authenticate" them in the browser and a refresh of the panel would then show them.  Now, no matter what I do they will not appear in a panel using URL-embedded authentication.

Yep, same here. I have many browser choices, but only Firefox on my main system EVER worked. Now, since one of the last updates a week or so ago that browser has been broke as well. Now none of the feeds directly from any of my cameras will show in ActionTiles. . .

Just wanted to share something I came across:

https://bugs.chromium.org/p/chromium/issues/detail?id=504300#c21

The metrics showed that use of such URLs was well below the normal threshold for deprecation.

So, this doesn't look good to Chrome ever supporting embedded credentials for basic authentication.

Although, I can (unfortunately) relate to the second quote from that thread:

However, no decision we make, including inaction, would please everyone.

I can't conceive of any universe in which making this supported via an "override option" would not please infinitely more people rather than "inaction" or "full deprecation".

Well, there's a cost associated with having a feature: regression testing, documentation maintenance, support, etc.

I just ran into this problem.  The latest HIKVision firmware 5.4.5 breaks the ability to use a base64 authenticatoin parameter.  But it still works with user:pass@ip.  . .. Chrome is a pain here.  

I tried getting snapshots from Surveillance Station, but it swamped the processor. . . .

So I put Firefox on my tablets and installed an add on called "full screen mobile" (the one by kregna or something like that).  So far it's working nicely.

I have the exact same problem using any browser - Including Firefox and fully - I need to authenticate separately the cameras access via Tinycam before I can see the pictures in AT tiles. this is going for a while now and I need to re-authenticate every week almost - very annoying

& I'm using in AT the full URL string which includes the user/password in it....

This is how it looks like in Firefox while it happens

Esalmo,

What type of Camera(s) are you using? I totally don't understand what you mean by this sentence:

 I need to authenticate separately the cameras access via Tinycam before I can see the pictures in AT tiles

I have 4 x Old Android phones acting as Cameras only via Tinycam pro which works great.

I have the same exact issue as Tamathumper pointed out in the very first post:

If I place my camera feeds on a panel as media tiles, on the first load they show as gray boxes with the "broken image" icon, until I click on one of them only to see the broken image enlarged - then I right-click and choose "view image" and then 
it asks for the Tinycam web server User/password. once they're authorized by the standalone single camera view I can go back to the panel, click Refresh and the panel displays all of the cameras correctly.

I tried to check with Alexy from Tinycam if there is an issue with the app web server but nothing came out of this investigation. 

You can see in the previous screenshot from firefox console that the URL for each camera include the User/password for the web server of the app. so I'm not sure why it's not working as it should.  

Esalomo,

1. The user and pwd in the URL in ActionTiles are the user and ID for the tinyCam Monitor Pro "mini-webserver" not for the underlying Camera(s) that the tinyCam App itself is connected to.
2. If you are prompted for a user/password while running ActionTiles, then you are very likely using the wrong values or wrong parameter names. It looks like you are using the correct parameters names (user, pwd).

https://192.168.0.3:8083/axis-cgi/mjpg/video.cgi?user=admin&pwd=mypassword  

Agreed and understood Terry, this is how things are already set-up in AT - address + port and U/P of the web server although I initially even set the individual cameras & the web server usernames and Passwords to be exactly the same as the web server one, just in case.

One question - I see that in your URL you put https while I'm using http only - should I switch? 

I searched the entire community forum but could not find this easy solution to get the media tile to work in Android.

My web camera (Dahua / IMOU) requires a username and password in the URL to work.  I got the web camera image to appear in a media tile both on a generic Android tablet and on an Amazon Fire tablet.

1.  Download the ActionTiles app from the Google Play or Amazon Store.

2.  Create a URL shortcut in the app (My Shortcuts) with the IP address of the web camera.  Do not include the username and password.

3.  When you click on the URL in the app, you will be prompted for the username and password to authenticate.

4.  Once authenticated, the webcam image will appear in the tile.

5.  You only have to do the authentication once.

6.  Solution also works by just using the browser.