New Web Client about audioserve HOT 21 CLOSED

from audioserve.

Looks good, for me I'd like to see duration and bitrate for each file (plus probably different icon for file).
Also how about transcoding functionality will be incorporated? For me this was one of main initial motivations (otherwise it could be just quite dumb webserver). For me it's quite distinguished feature of audioserve - it has transcoding working on large files, with possibility navigate there and shows correct duration. Not many others have that. Using transcoding has its quirks, so I understand you did not include it initially, but adding it late, when majority is done can also be problematic, cause it requires some special logic/approach many cases.

Possibility to cache content would be absolutely fantastic. I was looking bit into web workers and and cache api - did not get clear idea how to do it. Ideally should work on background and also support transcoding. So people can cache 48kbps opus, which has good quality(for audiobook) and saves a lot space/bandwidth. Also would be good to have feature similar to Android - preload and cache several files ahead as user is listening - plus have icon on file in browser when it's cached.

Must have feature is availability of last local position (folder, file, playback position) after browser reload/restart - many people praised this as other solutions usually do not have (as oriented on music - so it's not so important).

So these are few ideas.

from audioserve.

It's a work in progress bud :P

Transcoding will probably be the next major thing I look at as it is a nice feature to have. I'm not 100% sure how I'm going to deal with it yet so it will take a bit of playing around to see what is possible.

Caching content is already in and working. Clicking the dedicated button downloads and caches all the files in the folder, then when playing it pulls from the cache. If you don't click the button then it downloads the relevant file (based on the saved time position), caches it and plays the cache.

Currently, until last play position is available to set and get from the server I'm just storing it in indexeddb. But refreshing the browser already gets the current position.

from audioserve.

Currently, until last play position is available to set and get from the server I'm just storing it in indexeddb

Keeping it locally would be also good solution for future - server position tracking might not be so accurate or reliable or available (in case of offline PWA app).

from audioserve.

As I've said before, what I really want is an endpoint I can hit to save the group-book position, so that when pause is hit I can update that position, I will always keep a local copy as well (like you said for when offline), then maybe queue the position for when a connection comes back.

from audioserve.

I initially wrote a message, but deleted it as I dived into this more.

I'm still not sure what the best option is for dealing with transcoding. It looks like transcoding a file adds significant time to the download time, which is masked in the current implementation because you can stream what has already been transcoded while transcoding the rest (correct me if I'm wrong on that). Which means trying to download something like a large single file mp3 with chapters takes significantly longer even with transcoding turned off as it has to transcode each chapter into a separate mp3, rather than downloading the full file. Same with m4b's. They are also saved in the cache with a 0 Content-Length.

I have a couple of options:

• I could look for $$ in the file path, if it's there bypass the cache and just play the stream, I'll also have to look at getting the range bytes properly set in howler.js
• I could look at simultaneously playing the file and saving to cache (not sure this is even possible as I think a lock is placed on the readable stream), then when the cache has finished downloading switch to the cached version.
• I could make the user wait till the file has finished saving to cache before playing
• If $$ is in the file, download the entire file (quicker than transcoding part of the file in a lot of cases) and cache + play that.

Any thoughts on this?

from audioserve.

Would just extracting part of a file be any quicker than transcoding it as well? Like, for m4bs, could we grab 0 - 234345 and just send it as is?

from audioserve.

@KodeStar a lot of (very good) questions.
Many goes to explanation how digital audio formats work, how ffmpeg is used etc.
I think it's time to talk! Can we get together on online session Zoom etc. ? Can you pls send me email with your availability, we should move move meeting logistics from this thread. (If you prefer written communication it's OK, it'll take more time).

from audioserve.

@izderadicka email sent

from audioserve.

@KodeStar nothing received can you pls use this address [email protected]

from audioserve.

I've forwarded the email to that address

from audioserve.

Dark mode

from audioserve.

Initial support for playback history

from audioserve.

Looks nice - looks like history is related to particular file/chapter with both start and end - and playback speed? But values like 162.8x does not make much sense - meaning you have been doing some fwd jumps during playback.
That would be too much details for server.
Right now I'm working on rework of storing of history on server. It'll be the same 'approach' as before - storing last known position per folder (file+position) per group.
However in client I can see reason for maintaining much more detailed history.

from audioserve.

@izderadicka that's exactly what I was doing, usually that would show as (1.25x) as thats the speed I listen at. It's disappointing that you can't store simple json in a key value store, that's all I'm doing with this in indexeddb

from audioserve.

from audioserve.

@KodeStar
I'd like to keep server down to simple basics.
Indeed storing everything client sends would not be so complicated, but then:

• storage can grow quickly - will require to do some maintenance
• without careful check of incoming can be potential security weakness
• and I'm not convinced we need all these details at server

from audioserve.

Listen history is a much used feature that many people want. Prologue has it, Bookcamp has it, but it's pretty useless if it's not able to sync between devices. The amount of space it would take up is tiny, a full listening history for a book is likely to be less than 1KB per book, and could be made smaller by using less characters and rounding values, like:

0:
  s: 1632331555
  sS: 0
  e: 1632331578
  eS:  2677

It's a personal server implementation, groups don't even have logins, but yes, there could be security implications if you allowed anything at all to be stored.

Again, that's a shame, I'll do what I can within the confines I have to work in, but long term I may need to support other backends to get all the functionality I'd like.

from audioserve.

It's not that it never could be there. But now priority is to rework current simple position sharing to new model using sled KV store and especially assure synchronization between cached and stored data and changes in collection directory structure (what happens when folder is renamed). After this is finished we can look at other advanced features.

from audioserve.

Fair enough. Having thought on it over night a possible solution is for me to use something like firebase to sync the data I need syncing between devices, if can get that to work then I can just completely ignore the group stuff and save any book-group data in firebase instead.

from audioserve.

Closing - issues related to web client audiosilo could track at it's project

from audioserve.