You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
& is how JSON writes &: the debug page escapes <, > and & in strings, and any JSON reader turns it back into &. The app itself keeps the URL exactly as typed.
We checked this on our test box (2.13) with rtsp://…@<camera>/stream=0?ch=1&subtype=0&proto=Onvif. The full query, & included, reaches the camera (it comes back unchanged in the Content-Base header), and the stream plays.
Two things in your report differ, though. You typed …/H264?ch=1&subtype=0&proto=Onvif, but the saved slot shows …/h264?ch=1&subtype=0, with a lowercase h264 and without &proto=Onvif. The app doesn't lowercase or drop anything, so maybe it was typed that way in another attempt? Some cameras treat the path as case-sensitive.
Could you tell us:
Does the stream fail with the URL exactly as typed (/H264?ch=1&subtype=0&proto=Onvif)? What does the screen show: an error, a black picture, or the status line?
The camera brand and model.
If possible, http://<device>:8085/log right after a failed attempt (passwords are masked in it).
@sansarus, a gentle reminder about this one. We still can't reproduce it: on our side the URL with & reaches the camera unchanged, and & in the debug JSON is only how JSON writes &.
To go further we need three things from you:
Does the stream fail with the URL typed exactly as rtsp://…/H264?ch=1&subtype=0&proto=Onvif (uppercase H264, with &proto=Onvif)? What does the screen show: an error, a black picture, or the status line?
The camera brand and model.
http://<device>:8085/log right after a failed attempt (passwords are masked in it).
If it works for you now, just say so and we'll close the issue.
@sansarus, thanks, your report from #166 (2026-10-20 11:07) answers this one too: the & reaches the camera intact.
In the log, your camera at 192.168.1.86 sends back Content-Base: rtsp://192.168.1.86:554/H264?ch=1&subtype=0, with the & in place, so it got the full query.
The stream from that URL plays: H.264 1920×1080 on the hardware decoder (OMX.rk.video_decoder.avc).
& appears only inside stats.json: it is how JSON writes &, and any JSON reader turns it back into &. The URL in the app is stored exactly as typed.
So the app has no bug here, and I'm closing the issue. If a URL with & ever fails for you, please reopen it with the log of the failed attempt.
Activity
compot-dev commentedon Oct 16, 2026
Thanks for the report.
&is how JSON writes&: the debug page escapes<,>and&in strings, and any JSON reader turns it back into&. The app itself keeps the URL exactly as typed.We checked this on our test box (2.13) with
rtsp://…@<camera>/stream=0?ch=1&subtype=0&proto=Onvif. The full query,&included, reaches the camera (it comes back unchanged in theContent-Baseheader), and the stream plays.Two things in your report differ, though. You typed
…/H264?ch=1&subtype=0&proto=Onvif, but the saved slot shows…/h264?ch=1&subtype=0, with a lowercaseh264and without&proto=Onvif. The app doesn't lowercase or drop anything, so maybe it was typed that way in another attempt? Some cameras treat the path as case-sensitive.Could you tell us:
/H264?ch=1&subtype=0&proto=Onvif)? What does the screen show: an error, a black picture, or the status line?http://<device>:8085/logright after a failed attempt (passwords are masked in it).compot-dev commentedon Oct 20, 2026
@sansarus, a gentle reminder about this one. We still can't reproduce it: on our side the URL with
&reaches the camera unchanged, and&in the debug JSON is only how JSON writes&.To go further we need three things from you:
rtsp://…/H264?ch=1&subtype=0&proto=Onvif(uppercaseH264, with&proto=Onvif)? What does the screen show: an error, a black picture, or the status line?http://<device>:8085/logright after a failed attempt (passwords are masked in it).If it works for you now, just say so and we'll close the issue.
compot-dev commentedon Oct 20, 2026
@sansarus, thanks, your report from #166 (2026-10-20 11:07) answers this one too: the
&reaches the camera intact.192.168.1.86sends backContent-Base: rtsp://192.168.1.86:554/H264?ch=1&subtype=0, with the&in place, so it got the full query.OMX.rk.video_decoder.avc).&appears only insidestats.json: it is how JSON writes&, and any JSON reader turns it back into&. The URL in the app is stored exactly as typed.So the app has no bug here, and I'm closing the issue. If a URL with
&ever fails for you, please reopen it with the log of the failed attempt.sansarus commentedon Oct 20, 2026
& works well. it was my mistake with upper "H" and old fw.