Feature request: Advanced Handling of Audiobooks and Podcasts

[newhinton]

If the app would store playback positions and trackpositions for albums which have the id3metadata audiobook or similar, we would have a fully fledged audiobook app for nextcloud. If the api could be extended to allow downloading and querying for those audiofiles and timestamps, we could create a service which acts quiet similar to audible, where you can just continue listening to your audiofiles at any position on any device. I am willing to write such an app for android, and i would try to help with the extension of this app, or even implement it fully if i can get a little bit help from you. Just give me a hint if such features would be a good addition to this player!

This is somewhat related to #288, but extends this idea further

[Rello]

Hello, have a look at #332 regarding an app. I don´t know how far @watercool got with his idea.

We thought about the play-time-writeback already but did not implement it due to limited time and low usecase. but if you are willing to go for an app ontop AP, I would have a look at it.

questions:

• store the timestamp for every track or just the last played one?
• store a "playback active" indicator to recognise if the player was active or on standby?
• the writeback is a challenge regarding the timing. it will trigger a lot of ajax requests to the server. what do you think about the sequence? 10s? 30s? lower?

let me know...

[newhinton]

I would suggest to generally show the last played item, regardless of the mediatype (audiobook/music) but besides from that, i'd provide a list of types which are getting stored (podcasts, audiobooks, audioplays, cabaret etc) which are saved with timestamp, music would generally not be stored (besides the entry for last played album/title, but no timestamp)

also we can further reduce the required database entrys with treating an album as one audiobook, so we only have an entry for every album instead of every title

this should reduce the api calls. also the time interval in which the timestamp would be updated can be quiet low (30 secs or maybe more) because podcasts are often longer audiofiles so if you repeat 30secs it is not that bad

how are you hooking addons? through the nextcloud event dispatcher?

[newhinton]

i can try to do it as an addon, or directly embed it in this app, with a toggle or something in the settings. I'd prefer to directly embedded it and have it as a part of this app, but i could also try to do it as an addon, just say which approach you like more

[Rello]

the way it will be implemented is, that the data will be stored in the _stats table https://github.com/Rello/audioplayer/blob/master/appinfo/database.xml#L447

it would then store the playtime there every 30s why an update via the track_id - no matter what filetype or content. AP is generic here. This was prepared already some time ago and I need to check how to implement it already.

i can try to do it as an addon

what do you mean by this? AP will store this out of the box after an update. If you refer to an android app, this is completely different git-repo anyway. the approach would be that the app connects to the apis (see #332 for some discussions). I would create another api to retrieve the last played/timestamp

connecting to this would then enable the android app to continue where you left of on the browser. what do you think?

[newhinton]

@Rello Do you have a way to chat with you? i have questions regarding the structure, and it would be helpful if i could ask you some questions if you can spare the time

[Rello]

continuing in one issue to collect and document all requirements: #365

[chopfitzroy]

What is the status on this? I thought this would be a better place to ask than #365

[Rello]

Hello, I am looking at this for the upcoming release...

[Rello]

288