Unable to play video

Hi Team,

I am using Appium1.6.4
I am unable to play video on ios. this is same as

Is this issue fixed in latest releases or is there any work around.
please suggest

Thanks

1 Like

Hi,

We are experiencing a similar issue where we can click on a video and it starts but then it immediately stops.
Our testing is being done from scripts in Katalon but on devices in Browserstack and is only an issue when testing on the IOS devices.
We can get the videos to work when manually testing on IOS devices and when testing through Katalon in Browserstack on Android devices using Appium.
I have had the Browserstack support team look at the issue and they have said it is an issue with Appium.

Can you tell me if this issue is being looked at or is in the pipeline to be fixed?

Below are some of the platform versions we are using.
Appium version: 1.18.0
Katalon version: 8.3.5
Devices: Ipad Pro 12.9 2020 & Iphone 12
Browser: Safari

If you require any more information I am more than happy to provide it.

Thanks

I think it should be faster to track down the problem and fix the appium code manually. @DougL

You should have the BrowserStack team give more info on why they think it’s an Appium issue and where the problem is. Obviously they, and you are in the best position to reproduce the issue. I would work with them to file a bug in the appropriate Appium github.

This would require a description of the problem. Do you work in QA? Describe the problem as you would when reporting a bug for work. “Feature X doesn’t work, when will it be fixed?”, wouldn’t be acceptable for work, so you shouldn’t think that is acceptable here either.

Here is a nice article from BrowserStack describing what they would expect in a bug report:

Thanks very much @Dakota I will look into that.

Thanks for the suggestion @wreed I will go back to Browserstack and work further with them to get more information on the issue.
I also really appreciate your feedback and suggestion on how to write a Bug Report.

Something is really broken in this world where companies that make money using the software we work on for free (err, I get 6$ of GH donation per month for my work on OSS) send their paying customers back to us with issues.

In an ideal world I would expect them to invest more into OSS, I mean from both development resources and sponsorship perspective. At the end what is the point of setting up your business on something that you don’t have enough expertise in?

Perhaps we should enable an “evil enterprise mode” like Redis team did?

1 Like

@mykola-mokhnach agreed. If there is a bug, let’s call it out and get some eyes on it. But I don’t see a specific bug, or even a good definition of the problem.

I feel for @DougL as he probably feels caught in the middle. But if you are paying for support, your concerns should be addressed, not dismissed as, “Oh, that’s some bug in Appium”, which appears to have happened here.

I certainly expect that any company (especially in this hiring environment) will have a couple of people who are in over their heads. I have dealt with BrowserStack people in the past and they seem like a decent company on the whole. I advocate a push back on this particular instance, but that’s not a condemnation of the company at large.

Hi @wreed,

Firstly I just want to say that I have been working in QA for a couple of years now and while I have learnt a lot I am not a developer so I certainly struggle when it comes to the more technical issues so please bear with me.

I have contacted the Browserstack support team again as you suggested and will wait to see what they come back with. FYI in my dealings with Browserstack I have personally found their support to be excellent.

In the meantime below are 2 links to a replicated test that the Browserstack team setup and I am hoping will help give you some more information. I must also apologies as I should have sent them through at the start.

This ANDROID LINK is showing the test being run on an android device and it is working correctly with the video starting and running as it should.

This IPHONE LINK is showing the test being run on an Iphone and it is NOT working correctly as you will see the video is clicked on and the player pops up but the video does not continue to play.

You will see on those 2 pages that there is more information about the devices and platform versions etc being used in the 2 tabs called ‘Input Capabilities’ and ‘Device Capabilities’.
Also there is some logs which may be helpful including an Appium Log which can be found in the Other Logs => Appium tab.

This same test can be manually performed on the Browserstack Live platform using the same Iphone device and on my own personal actual Iphone and the video plays correctly which suggested to the Browserstack team that “as soon as Appium comes into the picture, the behaviour changes.”.

I hope that helps and thank you for all your help and suggestions.

I will be in touch again when I hear more from Browserstack.

Basically what you could do is to create a vanilla xctest and see how it behaves in the same scenario. xcuitest driver is just a wrapper over Apple’s xctest framework. Which means if the latter does not behave properly then there’s almost no way (only ugly hacks) to make it working with xcuitest driver.

You could also check my presentation on this topic to have better understanding on how xcuitest driver works.

First: Thanks for giving logs & video. It really does help to see what’s going on.

What I’m seeing in the logs and in the video look like a race condition. I would think this occasionally works.

Here is step by step what I’m seeing:

  1. browserstack standard url loads
  2. humancondition.com loads
  3. right as humancondition finishes loading, cookie notification shows & is clicked
  4. really fast scroll down to element “The Interview” <- log time: 07:39:26:573
  5. find element “The Interview” <- log time: 07:39:26:717
  6. click on “The Interview” <- log time: 07:39:26:925

Without looking at your code, it seems that the click happens maybe too quickly. Appium is known for this. Appium can click on an element so fast that it impossible to reproduce manually. I looked at that video and tried to scroll that quickly on the website you are testing, but was unable to do so.

I’m not seeing a bug here. I would suggest that some kind of ‘wait’ needs to be added to your code. There are waits for Selenium:

https://www.selenium.dev/documentation/webdriver/waits/

And Appium:

https://appium.io/docs/en/commands/session/timeouts/implicit-wait/

Either can be used in your code (Appium inherits from Selenium). Once again, I’d like to stress that this is the kind of advice you should be getting from BrowserStack support. I’m still disappointed that they did not offer any advice on how to mitigate such a problem. This is pretty standard Appium workflow.

If you run your Appium script on your iOS device you have same issue?

Ok thanks @mykola-mokhnach I will look into that.

Thanks very much for looking into the tests and Appium logs @wreed I really appreciate your help.

I was 99% sure that the problem is not happening because of a lack of delays I know this because of testing I have previously done, but just to be sure I did some testing to show you. Please note that the tests I put in my previous post were setup and run by the Browserstack support team where as the tests in this post have been setup and run by me from Katalon through Browserstack so some of the capabilities may differ.

This is the step by step from my Katalon test and is a very standard way I use delays except I added an extra couple of seconds after the scroll:

  1. Navigate to humancondition.com and it should wait for the page to load
  2. Delay 8 seconds
  3. Click the accept cookies notification
  4. Delay 1 second
  5. Scroll to the heading ‘The Main Videos’
  6. Delay 5 seconds
  7. Click the ‘The Interview’ thumbnail
  8. Delay 10 seconds
  9. Close the browser

From this Android Link you can see that the test passes and the video runs as it should.

From this Iphone Link you will see that the test video popup opens and the video seems to start(?) but then stops running which is wrong.

Anyway I hope that helps.

Also Browserstack support has got back to me and they are happy to have their engineers look at the problem in more detail but they have asked me the same question @Aleksei asked me which was ‘do I have the same issue when I run the Appium script on my personal iOS device?’, so I am setting that test up and will reply in due course.

Thanks again.

I’ve spent some time today trying to reproduce with Appium Inspector. Works every time. Tried in both Safari and Chrome. :man_shrugging:

iPhoneSE (Version 2)
iOS 15.0
Appium 1.22.0

Here is a video of me using Appium Inspector to click the link. I have a QuickTime player mirroring the iPhone screen. The only difference (I think) is that I’m getting the element by id, which returns 5 elements and I’m selecting the first. Also, FYI, I have seen the kinds of failures that you are seeing, but they are intermittent. Most of the time it works just like the video:

https://vimeo.com/730480089

Hi @wreed,

Thanks very much for doing that testing, I forwarded your video onto the Browserstack support team and as a workaround/solution they have come back saying to use a “nativeWebTap” instead of a standard “click”.
Unfortunately I have to set this in the capabilities for a test suite in Katalon which means you are using “nativeWebTap” for the whole test which I have had problems with in the past, but I have been able to get everything we need to work so I am happy with this solution.

We are already using this feature else where in our testing and I thought about trialing it as a solution to this issue but because the click was working and bringing up the popup I assumed that the issue was not with the click. You know what that say though “Assumption is the mother of all stuff ups” and it is something I should have tried!

As to the actual reason why the click is not working I still do not really know and the Browserstack support team said it can be “various and complex” but gave me an explanation of what the nativeWebTap is doing differently to a standard click.

So thank you and everyone else for all of your help and guidance, it was very helpful in finding a workable solution and I really appreciate it.

1 Like

Good Luck to you, Doug.