2014-02-17, 09:37 PM (This post was last modified: 2014-02-17, 09:55 PM by odin.)
thanks for your work on this Brian.
I think I've found the reason for the long term bug on playing back recordings.. (Edited to say this looks like it was reported previously in this thread also)
When you play back a previous recording, if there is a space in the recording name (directory), then the recording does not play. However, if there is no space, then the recording plays.
Example:
All recordings under the 'Hostages' directory play without issue, but no recordings in the 'Body of proof' directory play at all.
vanderwelc Wrote:1. selecting watch now from any show under what's new appears to append the full path to the url(based on the error from gplayer) any path with a space is not working, e.g. d:\tem\media watch\media watch_2014.....ts will error in any player i have installed (no Transcode)
odin Wrote:I think I've found the reason for the long term bug on playing back recordings.. (Edited to say this looks like it was reported previously in this thread also)
When you play back a previous recording, if there is a space in the recording name (directory), then the recording does not play. However, if there is no space, then the recording plays.
I can't reproduce this - I admit I have various recordings which don't playback well (still suspecting a change in MX Player as I'm sure they did previously).
The issue with spaces doesn't apply though. I just played back an episode of "Call the Midwife" from Recordings and it worked.
Extract of nDroidServiceStreamer.log...
Code:
18/02/2014 10:54:40.842 ProcessRequest() called...
18/02/2014 10:54:40.842 URI: http://192.168.0.5:8791/D:/nPVR/Call%20the%20Midwife/Call%20the%20Midwife_20140216_20002100.ts
18/02/2014 10:54:40.842 URI filename: /D:/nPVR/Call the Midwife/Call the Midwife_20140216_20002100.ts
18/02/2014 10:54:40.842 Local filename: D:\nPVR\Call the Midwife\Call the Midwife_20140216_20002100.ts
The first URI: log entry is what was sent by MX Player in its request and is what the nDroid app would have passed to MX Player in the first place so it shows the URI is correctly encoding space characters as %20. The ndroid service end then decodes the URI resulting in the local filename. After that the service just dumps 250000 bytes of the file in chunks for the player to grab at which point the filename isn't even used - just the http session.
2014-02-20, 01:32 PM (This post was last modified: 2014-02-20, 01:43 PM by odin.)
Hi Brian, here is a log extract from one of my troublesome recordings. This does not work on any of my Android clients using the newer Ndroid TE with MX Player and default video players.
It DOES however work in the older Ndroid application using MX Player and the default video player
Do you think therefore this is an issue with Ndroid TE and thus ruling out MX Player?
2014-02-20, 11:22 PM (This post was last modified: 2014-02-21, 12:13 AM by bgowland.)
odin Wrote:It DOES however work in the older Ndroid application using MX Player and the default video player
Do you think therefore this is an issue with Ndroid TE and thus ruling out MX Player?
Logically? No. Don't get me wrong - I believe you're seeing what you're seeing but I've got both the nDroid v1.9 project and nDroid TE v2.1 project open at the moment and there's no difference in how v1.9 starts a video player compared to the way TE does it. Besides, as I've said before, once a video player starts it has full control of the process and the nDroid app basically goes to sleep.
Could you try playing that same recording with nDroid v1.9, let it play for a minute or so then stop it. Then try playing it from TE and then post the log to include both. It may also be useful to include the other nDroid service logs. If the logs show MX Player behaving differently when started from v1.9 compared to when it's started from TE then I've obviously missed something in my code.
EDIT: Yeah, I'm definitely missing something here - I've finally been able to reproduce some different behaviour in MX Player when started from v1.9 and TE on some of my recordings. Most of my recordings behave fine (typical...that's why I couldn't reproduce what you're seeing). At least now I've got something to test against so I can see what's being passed to MX Player from each version. Hopefully I can find a fix.
I dug further into the v1.9 code and found what it was doing differently. I'll look through the other issues that have been mentioned WRT v2.1.0 and put v2.1.1 out later today or tonight.