Opened 4 years ago

Closed 3 years ago

#13001 closed Patch - Bug Fix (Won't Fix)

[patch] fix WebFrontend user agent detection on Apple systems

Reported by: ctreleaven@… 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


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)

patch_01_typlayer_qsp_ua_detection.txt (553 bytes) - added by ctreleaven 4 years ago.
browser modified WCT 2017Feb19.jpg (88.3 KB) - added by ctreleaven@… 4 years ago.
screen capture - Mac -- watch recording in browser

Download all attachments as: .zip

Change History (11)

Changed 4 years ago by ctreleaven

comment:1 Changed 4 years ago by Stuart Auchterlonie

Milestone: unknown0.28.2

comment:2 Changed 4 years ago by ctreleaven@…

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.

Changed 4 years ago by ctreleaven@…

screen capture - Mac -- watch recording in browser

comment:3 Changed 4 years ago by ctreleaven@…

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 4 years ago by ctreleaven@…

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 4 years ago by stuartm

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 4 years ago by stuartm

Status: newaccepted

comment:7 Changed 4 years ago by stuartm

Might also be worth testing alternative, forward compatible approaches to support detection such as this one -

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 4 years ago by Stuart Auchterlonie

I think we should consider using the opensource video player at in future....

comment:9 Changed 3 years ago by Stuart Auchterlonie

Resolution: Won't Fix
Status: acceptedclosed

Closing any remaining tickets for 0.28, if the issue persists, feel free to reopen and align to v29 or master

Note: See TracTickets for help on using tickets.