Re: Video files not streaming on mobile devices - ZMS only

"Robert Buchholz [email protected] [zms-developers]" <[email protected]> Wed, 11 Nov 2015 17:10:52 +0100
Newsgroups gmane.comp.cms.zms.devel
Message-ID <[email protected]>
--gadLlcKxlUQ2v6b06KxXfOupme4SfFfLa
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hallo,

I don't think ZMS's file serving code handles the HTTP "Range" header,
which is required by iOS to stream videos:
https://developer.apple.com/library/prerelease/ios/documentation/AppleAppli=
cations/Reference/SafariWebContent/CreatingVideoforSafarioniPhone/CreatingV=
ideoforSafarioniPhone.html#//apple_ref/doc/uid/TP40006514-SW6


Best,

Robert



On 09.11.2015 13:21, Sebastian T=C3=A4nzer [email protected] [zms-developers] w=
rote:
> Hi Hiels,
>=20
> thanks a lot. From what I see this is related to the FileFromData functio=
n that is used to created blob fields programmatically. We=E2=80=99re not d=
oing that. In our case the user simply uploads a video file in a file field=
, nothing else. Storing is handled by ZMS just fine. The file does not come=
 from the ZODB, definitely not. The file is in the mediadb folder in the sy=
stem and returned from there (deleting the file physically in the folder ac=
tually causes an error)
>=20
> The problem we=E2=80=99re experiencing seems to be related to the way ZMS=
 handles HTTP reponses of this data as there is a special HTTP =E2=80=9Estr=
eam=E2=80=9C method in the native OFS.File source.
>=20
> Our headers we set by our python script to return the video are _exactly_=
 the same.
>=20
> I=E2=80=99ll play a bit more with this and will post my insights :-)
>=20
> Best
> Sebastian
>=20
>> Am 09.11.2015 um 13:16 schrieb Niels Dettenbach [email protected] [zms-dev=
elopers] <[email protected]>:
>>
>> Am Montag, 9. November 2015, 12:55:52 schrieben Sie:
>>> Hey Niels,
>>>
>>> thanks for the quick reply. We are in fact using mediadb and from what =
I see
>>> the files do come from the filesystem. Doesn=E2=80=99t ZMS take care of=
 this itself
>>> when using getData() on a file field?
>>
>> If i remember right, i had to change this method to get a generated file=
 from a special db into the mediadb (when required):
>>
>>    # -------------------------------------------------------------------=
-------
>>    #  ZMSGlobals.FileFromData:
>>    # -------------------------------------------------------------------=
-------
>>    def FileFromData( self, data, filename=3D'', content_type=3DNone, med=
iadbStorable=3DFalse):
>>
>> before:
>>
>>    def FileFromData( self, data, filename=3D'', content_type=3DNone ):
>>
>> otherwise each generated file from a onChangeObject is landing in the ZO=
DB instead of a configured mediadb. If i remember right, with Images / Imag=
e blobs this was working out of the box instead.
>>
>>>
>>> My problem is that the data return from the mediadb by ZMS does not wor=
k
>>> with video files - any other files work just fine. The files themselves=
 do
>>> not reside in the ZODB but in the filesystem.
>>>
>>> I=E2=80=99d love to see your code snippet to read the actualy file from=
 the mediadb.
>>>
>>
>> ...just out of my work,
>> this works here so far for MP3s in a web player and in iTunes. If i reme=
mber right, i had to fiddle with the correct Headers a while. So may be thi=
s could bring you on a way it works for you (hope so)...
>>
>> Cleaned out a bit from stuff not relevant here. Some of the headers are =
gone to the frontend proxy, so this may be incomplete or lines are commente=
d out. No guarantees so far!!!
>>
>> request =3D container.REQUEST
>> RESPONSE =3D request.RESPONSE
>> session =3D context.REQUEST.SESSION
>>
>> RESPONSE =3D  request.RESPONSE
>> counted =3D False
>>
>> try:
>>  if context.getObjProperty('audiofile_playout',request):
>>     file=3Dcontext.getObjProperty('audiofile_playout',request)
>>  else:
>>     file=3Dcontext.getObjProperty('audiofile',request)
>>
>>  #filetype=3Dfile.getContentType()
>>  filetype=3D"audio/mpeg"
>>  filename=3Dfile.getFilename()
>>  filesize=3Dfile.getDataSizeStr()
>>  fileurl=3Dfile.getHref(request)
>>
>>  # rise in object request counters
>>  try:
>>     # count on the ad
>>     # -> remember last played/requested url
>>     context.countMP3Requested()
>>
>>     # generates cookie / session if required
>>     #if not session.get('last_played_id'):
>>     #   session.set('last_played_id','no')
>>
>>     counted =3D True
>>  except:
>>     counted =3D False
>>
>>  RESPONSE.setStatus('200')
>>  #RESPONSE.setHeader('Cache-Control', 'no-cache')
>>  RESPONSE.setHeader('Content-Type', filetype)
>>  RESPONSE.setHeader('Content-Length', filesize)
>>  RESPONSE.setHeader('Content-Disposition','attachment;filename=3D%s'%fil=
ename)
>>
>>  return file.getData()
>>
>> except:
>>  RESPONSE.setStatus('404')
>>  return 'Error: File not found'
>>
>>
>> good luck,
>>
>>
>> Niels.
>>
>> --
>> ---
>> Niels Dettenbach
>> Syndicat IT & Internet
>> http://www.syndicat.com
>> PGP: https://syndicat.com/pub_key.asc
>> ---
>>
>>
>>
>>
>=20


--=20
Mit freundlichen Gr=C3=BC=C3=9Fen
Robert Buchholz
-----------------------------------------------------------
yeepa Software Engineering
mailto:[email protected]
-----------------------------------------------------------
yeepa is a registered trademark of
SNTL Publishing GmbH & Co KG
Hegelplatz 1, 10117 BERLIN
T: ++49-(0)30 - 209 127 8-4
F: ++49-(0)30 - 209 127 8-1
www.sntl-publishing.com
[email protected]
-----------------------------------------------------------


--gadLlcKxlUQ2v6b06KxXfOupme4SfFfLa
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWQ2iMAAoJEKZK0qp6IqRx3o8P/iM+XjpgXki2WHF+eJhvsqDj
nNfB8Req8bNEEv54KUwfTCYDBGwsY/wMeAYGSxuQORh+Va+gRCA5SgVIctkAX4h9
2IWG8i2EYCyZx69NLyr+qZf8UQVPoEp9ah6dSXx+buOFheew5n9fthD3D0MXXVjG
ahN+IdxsokW9pL9MbPE9z5wQ5T9xYUq4fecjul14F/ZiISyjSelAf12Lpt59WBqb
D7czjZGmHLCdyN0J9PzkeJsH/ql1GCV3BbkjimL10HL4VnvD8fKu8Lh4kLf05FhG
Ins1o7qlg9PqLcwrCU9W7UlS3AWLWdZDg6PcasxAzSktHJEjW1rv84H6joW5XPLN
k/AA7rZXEmeDDGEvJOjvXqjqt7OyOkhPsnBOcSUZuPDy3lFj3AfOQEHjB93Y1zfc
izjpN5ZTWSjWyVRdk2lwz1VOMXteYhhtzTKvw/8u6x3ZsrUJIpBibvL5Q+zep+v4
BTtClXrsWLeO9GYms05kT+D4LoBnqcPqzXASJUbYNMtfsx5Akw1pQfPqIDBZwDtM
u9wht9f0NgjVyRwj163DjUVOgckWpcwUZHUN/oSD2GTWzqANGQrfUC1Z6ZK8pd1i
73sfTJdVhONnFeDQxh1XgwTxDJBJPbqYSVafVbampyBU9e9tURfD2SujXfjolg8n
iupS483hHPtlWBne+jUR
=D/Lb
-----END PGP SIGNATURE-----

--gadLlcKxlUQ2v6b06KxXfOupme4SfFfLa--