Opened 7 years ago
Closed 6 years ago
#13001 closed Patch - Bug Fix (Won't Fix)
[patch] fix WebFrontend user agent detection on Apple systems
Reported by: | Owned by: | stuartm | |
---|---|---|---|
Priority: | minor | Milestone: | 0.28.2 |
Component: | MythTV - Web Frontend | Version: | 0.28.1 |
Severity: | medium | Keywords: | user agent detection Apple Macintosh |
Cc: | Ticket locked: | no |
Description
One line patch to fix WebFrontend?'s user agent detection for 'Watch in browser'.
The Safari browser on OS X is capable of HLS; need to add "macintosh" as an acceptable user agent.
The user agent header is retrieved and converted to lower case but is being compared to "iPhone" and "iPad"--need to change case to "iphone" and "ipad".
Attachments (2)
Change History (11)
Changed 7 years ago by
Attachment: | patch_01_typlayer_qsp_ua_detection.txt added |
---|
comment:1 Changed 7 years ago by
Milestone: | unknown → 0.28.2 |
---|
comment:2 Changed 7 years ago by
Changed 7 years ago by
Attachment: | browser modified WCT 2017Feb19.jpg added |
---|
screen capture - Mac -- watch recording in browser
comment:3 Changed 7 years ago by
Screen grab shows video playing in Safari (Mac OS X 10.11). Note that player controls are hidden but become visible if the mouse is moved over the lower portion of the video window.
comment:4 Changed 7 years ago by
Final observation: the "Download" function actually plays the untranscoded video. Safari must detect that it is receiving a video stream and puts up the standard video player window. (The other elements shown in the screen capture don't appear. No title, subtitle or description, etc.) Not sure if Play/Pause? works or not.
comment:5 Changed 7 years ago by
At the time this was written I didn't have a Mac to test with, I now do although at the current moment I'm separated from it by a few thousand miles.
The patch looks fine. I For the 'Download' issue, we should be setting the 'Content-Disposition' header, which on most browsers is interpreted as 'download' instead of 'handle' the content. I thought I had done this, with it specifying a user-friendly filename at the same time but this doesn't appear to be the case in the current master meaning I must have forgotten to commit it a couple of years back. Whoops.
After all this time, I've no idea if I'll be able to find the original patch in git stash or a branch, it might be faster to do it again from scratch. Fortunately, I have a little free time in the evenings at the moment so I'll look at adding this.
comment:6 Changed 7 years ago by
Status: | new → accepted |
---|
comment:7 Changed 7 years ago by
Might also be worth testing alternative, forward compatible approaches to support detection such as this one - https://stackoverflow.com/questions/12410132/html5-video-how-to-test-for-hls-playing-capability-video-canplaytype
This is a client side approach instead of the current server side one and it looks for browsers which list support for the HLS mimetype. However, I don't know which browsers actually correctly report this apart from Safari.
comment:8 Changed 7 years ago by
I think we should consider using the opensource video player at http://videojs.com/ in future....
comment:9 Changed 6 years ago by
Resolution: | → Won't Fix |
---|---|
Status: | accepted → closed |
Closing any remaining tickets for 0.28, if the issue persists, feel free to reopen and align to v29 or master
In addition, the playerControlBar starting at line 97 in html/tv/tvplayer.qsp (same file) is unnecessary on Apple platforms. The standard video player comes up and has play/pause, volume and other widgets that automatically appear when needed and fade out after a few seconds. Those controls seem to work fine when playing a (transcoded) MythTV recording.
I'm just commenting out the block for the sake of testing.