Closed curtishall closed 1 week ago
I'm not sure if this is related, but currently the video duration returned by the server is incorrect and does not match the actual video duration.
I'm not sure if this is related, but currently the video duration returned by the server is incorrect and does not match the actual video duration.
@bdlukaa probably is related, thanks for replying!
What does it return? How does the client make its requests?
What does it return?
The video duration is defined by the following rule:
event update date - event publish date
.
This is how the event are fetched: https://github.com/bluecherrydvr/unity/blob/f579c61f1cc0f54bf1cd14e0fc51b23fa9729951/lib/api/events.dart#L83-L201
Maybe it is an issue with the way the client fetches things or is the rule above wrong? Should I make use of media_duration
?
This is how the event are fetched: https://github.com/bluecherrydvr/unity/blob/f579c61f1cc0f54bf1cd14e0fc51b23fa9729951/lib/api/events.dart#L83-L201
Maybe it is an issue with the way the client fetches things or is the rule above wrong? Should I make use of
media_duration
?
Thanks a lot for coming here and sharing this!
So indeed the client app is what causes the code in eventIndex.php to run. The data returned has the following shape, so you can use eventObject['content']['media_duration']
. But not eventObject['media_duration']
!
It's interesting that eventObject['duration']
(as in line 201 of events.dart) would have worked if the data came from www/ajax/playback.php, which does a very simiar database query and formats the output data in a similar shape, but that data is never exposed to data-centric API, instead it shoves that data into a "view" defined by the template www/template/ajax/playback/listEvents.php which returns HTML which is presented on the Playback page in web UI. So duration data in Unity client likely never worked, but soon it should start working, once this PR is merged and we release 3.1.8 or so :)
$ bash -x events-client-api.sh
+ curl -k -v 'https://admin:bluecherry@192.168.86.138:7001/events/?XML=1&limit=-1&' -H 'Cookie: bluecherrydvr=dqb331q1m1e0iui8cb0s2uvvpt'
* Trying 192.168.86.138:7001...
* Connected to 192.168.86.138 (192.168.86.138) port 7001
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / RSASSA-PSS
* ALPN: server accepted http/1.1
* Server certificate:
* subject: CN=ubuntu-24-04-p
* start date: Nov 11 02:18:08 2024 GMT
* expire date: Nov 9 02:18:08 2034 GMT
* issuer: CN=ubuntu-24-04-p
* SSL certificate verify result: self-signed certificate (18), continuing anyway.
* Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/1.x
* Server auth using Basic with user 'admin'
> GET /events/?XML=1&limit=-1& HTTP/1.1
> Host: 192.168.86.138:7001
> Authorization: Basic YWRtaW46Ymx1ZWNoZXJyeQ==
> User-Agent: curl/8.6.0
> Accept: */*
> Cookie: bluecherrydvr=dqb331q1m1e0iui8cb0s2uvvpt
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/1.1 200 OK
< Server: nginx/1.24.0 (Ubuntu)
< Date: Mon, 18 Nov 2024 14:25:53 GMT
< Content-Type: application/json
< Transfer-Encoding: chunked
< Connection: keep-alive
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
<
{
"title": "Bluecherry Events for ",
"updated": "2024-11-18T14:25:53+00:00",
"id": "urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6",
"link": {
"rel": "self",
"type": "application\/json",
"href": "http:\/\/\/events\/"
},
"generator": {
"uri": "http:\/\/www.bluecherrydvr.com\/atom.html",
"version": "1.0",
"content": "BluecherryDVR Events Atom Generator"
},
"entry": [
{
"id": "http:\/\/\/events\/?id=971",
"title": "info: continuous event on device 192.168.86.148",
"published": "2024-11-18T14:21:34+00:00",
"category": {
"scheme": "http:\/\/www.bluecherrydvr.com\/atom.html",
"term": "3\/info\/continuous"
},
"content": {
"media_id": "944",
"media_size": null,
"media_duration": null,
"content": "https:\/\/192.168.86.138:7001\/media\/request.php?id=944"
}
},
{
"id": "http:\/\/\/events\/?id=970",
"title": "info: continuous event on device 192.168.86.200",
"published": "2024-11-18T14:17:49+00:00",
"category": {
"scheme": "http:\/\/www.bluecherrydvr.com\/atom.html",
"term": "2\/info\/continuous"
},
"content": {
"media_id": "943",
"media_size": null,
"media_duration": null,
"content": "https:\/\/192.168.86.138:7001\/media\/request.php?id=943"
}
},
...
We don't use media_duration, we use video_duration!
PHP message: PHP Notice: Undefined index: media_duration in /usr/share/bluecherry/www/ajax/events/eventsIndex.php on line 128
root@fvi-bcdvr1:/usr/share/bluecherry/www/ajax/events# grep "media_duration" /var/log/nginx/bluecherry-error.log |wc -l 243107