-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Asynchronous music-metadata updates while streaming #1449
Asynchronous music-metadata updates while streaming #1449
Conversation
@codealchemist Can you please review these changes? Note that the dependency of music-metadata is not updated yet. At this time you need to checkout feature/async-updates branch of music-metadata, which is still a pending pull request. You can yarn to link to your local music-metadata branch. |
Oh, I can't play any files on first try. Just wanted to say this is awesome stuff! |
BTW, I installed |
I am looking forward to your feedback!
I guess that is not working, because the TypeScript in music-metadata is not getting compiled. I use yarn, to link the local checked out dependency. git clone https://github.com/Borewit/music-metadata.git
cd music-metadata
git checkout feature/async-updates
yarn install
yarn build
yarn link
cd ../webtorrent-desktop
yarn link music-metadata |
This is the test set I am currently using: Audio torrent test set v01.zip The MPEG-4 Audio Book File in 'Glories of Ireland 1801 librivox (audio book).torrent', are not working yet. That is why I started:
As a reminder for an entry on the change-log and to ensure it got tested I created: #1452 Something else I noticed: suspiciously frequently, the track number is not visualized. |
… defined (common.track.of === null).
…track, disk, album, format
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested with mp3 and ogg and it's working, yay!
I saw 13 async calls which initially looked like too many, but we might not be using all the data we get.
Didn't have time to check that yet.
Great work @Borewit !
src/renderer/webtorrent.js
Outdated
skipCovers: true, | ||
fileSize: file.length, | ||
observer: event => { | ||
console.log(`async-audio-metadata-update: file='${file.name}', type=${event.tag.type}, tag-id=${event.tag.id}`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can remove this extra logging before merging.
:)
@@ -216,9 +216,7 @@ function renderAudioMetadata (state) { | |||
const elems = [] | |||
|
|||
// Audio metadata: artist(s) | |||
const artist = common.albumartist || common.artist || | |||
(common.artists && common.artists.filter(function (a) { return a }).join(', ')) || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
common.artists
array is not available anymore?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is still available, but common.artist is already designed to summarize the artist(s) in a single string.
Either derived from common.artists or directly from the metadata.
In other words, the code removed is already done in music-metadata.
There maybe indeed calls now which do not effect any visual change because the metadata triggering the call is not used. I thought about this, and assumed these callback were not to expensive. But the source of all evil in the world are assumptions ;-). To keep things simple I decided not to filter the events, but that can be done if you think it is worth it. |
#1452 Fix for playing some '.m4b' files
About having extra async calls I think it's ok. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good!
Thanks!
@codealchemist Thanks for reviewing, I think this one made a good difference. I just found out that there are some cases where events are not triggered yet. Which may not be even noticeable for the end user, Fixed.
I am not so sure about putting the filter in music-metadata. I don't think that is any better then just do something with the event which we are interested in. Callbacks are generated in music-metadata, with or without one listening in the app, because conversion and merging has to take place to maintain the common model. I would go for |
…metadata' and 'fix/audio-track-nr' of https://github.com/Borewit/webtorrent-desktop into feature/async-update-music-metadata
src/renderer/lib/migrations.js
Outdated
// Config is now on the new version | ||
state.saved.version = config.APP_VERSION | ||
} | ||
|
||
// Whenever the app is updated, re-install default handlers if the user has | ||
// enabled them. | ||
function installHandlers (saved) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this enhancement is worth its own PR.
But if the other folks agree we can add it here.
Really nice catch BTW :)
# Conflicts: # src/renderer/webtorrent.js
@mathiasvr this one should be good for merging as well. |
Maybe it is not relevant to this PR, but doesn't the metadata streaming force webtorrent to download the file sequentially, even if the user wants to seek to a position later in the file? Anyway, I think we can merge this and consider potential optimizations later. A couple of things:
|
Not sure if the metadata is also driving the sequential download. But if metadata doesn't trigger it, the audio player will do for sure will, despite the fact that you want to start playing half way for multiple reasons:
Although it is depending on the file format and provided settings, music-metadata doesn't read necessary to the end of the stream, in many cases, a relative small portion of the beginning of the stream is sufficient. I have the impression the sequential download is already prioritized at the moment you navigate to the audio track "page". For sure this PR doesn't change the way the audio metadata is read, that's the same is as before. It starts to display metadata during parsing. But if you see a way how we can do things smarter, I will look into it.
Regarding that commit, for sure I did not inject that on purpose. Neither I see it ending up the changes, so I suppose is not part of the PR. Maybe I made mistake at some point and falsified the history of the branch. So sorry.
Sounds good to me. |
….0' into feature/async-update-music-metadata # Conflicts: # package.json
Sounds good, in that case I do not see a problem. 👍
Yes that looks pretty weird? However I still see it in GitHub changes view, and also when manually pulling your branch to the master. Can you try to rebase your branch? Otherwise if you check Allow edits from maintainers on this PR, I can try to do it. |
Oh I see what you mean, it is part of the change-set, overlooked that. Allow edits from maintainers is and was granted Mathias, be my guest. This is my last PR on a branch created in my clone, I will use webtorrent repo straight away in the future, much easier. |
…fter updating." This reverts commit 39145b2.
Thanks Mathias! |
Implementation of asynchronous tag update events (send each time music-metadata founds a new generic tag or format change while it is parsing the downloaded stream build up from the torrent chunks).
Solution for #1340: Improve the music metadata reading and updating mechanism