INTERACT FORUM
Networks and Remotes => Remotes => Topic started by: aaronsama on May 18, 2015, 11:09:27 pm
-
JRemote is amazing. One feature request, if possible: Is there a way to have it pick up where it left off when to start it back up after a long delay? Currently, if you let it idle too long, it disconnects, and when it restarts it doesn't remember what you were listening to, and the now playing list is cleared. It would be wonderful to have it keep the current playing song loaded, at the spot last played, and the now playing list current as well.
-
Seconded. It's basically the same as my request for automatic bookmarking. Very frustrating to lose your place in a long ebook.
-
Seconded. It's basically the same as my request for automatic bookmarking. Very frustrating to lose your place in a long ebook.
Or audiobook :)
-
I don't really care about retaining the Playing Now list, but this I'd really like to see:
Seconded. It's basically the same as my request for automatic bookmarking. Very frustrating to lose your place in a long ebook.
Or audiobook :)
+1 on that.
-
If they make JRemote a playback zone that'll fix that problem. hint hint :)
-
If they make JRemote a playback zone that'll fix that problem. hint hint :)
Only if they fix the DLNA server so that it supports byte-range seeks. hint hint :)
-
They don't have to fix DLNA to do this in JRemote. MCWS != DLNA. ;)
-
They don't have to fix DLNA to do this in JRemote. MCWS != DLNA. ;)
True, but if I am not mistaken it is the same server that serves the files. If it cannot support a seek, it can not support a seek, no matter what hat it is wearing...
-
It is the same server process, but the code paths could be very different internally. We dunno.
I was mostly picking on you, though.
If it were me, I wouldn't want to support the fail that is DLNA at all, for spite. ;D
-
True, but if I am not mistaken it is the same server that serves the files. If it cannot support a seek, it can not support a seek, no matter what hat it is wearing...
Actually we support time-based seeking, both through DLNA and MCWS, so JRemote needs zero changes in MC to do this.
In fact, MP3 streaming should even support byte-seeking, as we use a strict CBR encoder, but then audio streaming is quite distinct from video in the code.
I'm not sure about this feature though. Doesn't MC itself not even do this for audio files? I don't think i ever saw it create a bookmark for a song, but I'm not I ever bothered to really check properly.
Maybe its tied to the subtype, ie. do it for audiobooks?
For video it makes sense, of course.
-
Maybe its tied to the subtype, ie. do it for audiobooks?
Yes. It is tied to [Media Sub Type], or can be overridden by the [Use Bookmarking] field.
By default, bookmarks are obeyed on:
* Video
* Audiobooks
* Podcasts
* Any file where Use Bookmarking is enabled manually
JRemote does not currently obey any of this, and never obeys bookmarking (and doesn't set bookmarks on things it has played either). I'd like it to follow exactly the same rules as MC. In particular for Video playback (which makes seamlessly switching between playing video on JRemote and the HTPC possible) and audiobooks. I don't use JRemote for podcasts, but while you're at it, you might as well follow the same rules.
EDIT: Linkage:
http://yabb.jriver.com/interact/index.php?topic=51531.msg351664#msg351664
-
Actually we support time-based seeking, both through DLNA and MCWS, so JRemote needs zero changes in MC to do this.
Yup. And as you know the file size and its duration (from the tags) you can actually always convert an external byte range seek request to an internal time based seek; so I just don't understand why you won't do it; it's so simple. Rant. Rant. :)