supernginx / flowplayer-core

Automatically exported from code.google.com/p/flowplayer-core
0 stars 0 forks source link

onMetaData not reliable with audio playlists #582

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1.
plugins: {
  controls: {
    playlist: true, autoHide: false, fullscreen: false
  },
  content: {
    url: 'flowplayer.content-3.2.8.swf'
  }
},
clip: {
  baseUrl: 'http://media.blacktrash.org',
  onStart: function (song) {
    var meta = song.metaData;
    this.getPlugin('content').setHtml(
      'Artist: ' + meta.TPE1 + ', ' +
      'Track: ' + meta.TRCK + ', ' +
      'Title: ' + meta.TIT2
    );
  }
},
playlist: ['song1.mp3', 'song2.mp3']
2. play song1
3. play song2
4. jump back to song1
5. metadata not updated

What is the expected output? What do you see instead?
Expected: jumping back to song1 also updates the meta information
Instead: metadata of song2 is still displayed

Workaround: use onStart

onMetaData is the black sheep of events it seems. Either it's triggered more 
than needed (issue558) or not enough.

See also: http://flowplayer.org/forum/5/100632

Original issue reported on code.google.com by blacktrashproduct on 1 Jun 2012 at 11:35

GoogleCodeExporter commented 9 years ago
Obviously the sample code above should use onMetaData and not onStart, sorry.

Original comment by blacktrashproduct on 1 Jun 2012 at 11:37

GoogleCodeExporter commented 9 years ago
jump back as it replay. for some reason, it does not replay properly its stuck 
in a mode that wont come out of pause mode in the player, the scrubber starts 
at the end, onstart is not sent, however it seems to be disaptched internally 
on the id3 event, the id3 tag displays the correct information on replay. 

[LOG] time 03:11:50.215 :: org.flowplayer.audio::AudioProvider : onId3(), 
_started == false
[LOG] time 03:11:50.216 :: org.flowplayer.audio::AudioProvider : current 
metadata
[Array] 
[Object] 
[String] TYER = 2007
[Number] duration = 205.1134693877551
[String] TPE1 = The National
[String] TRCK = 1
[String] TCON = Indie
[String] TALB = Boxer
[String] TENC = Exact Audio Copy   (Secure mode)
[String] TIT2 = Fake Empire
[LOG] time 03:11:50.224 :: org.flowplayer.audio::AudioProvider : TYER: 2007
[LOG] time 03:11:50.225 :: org.flowplayer.audio::AudioProvider : TENC: Exact 
Audio Copy   (Secure mode)
[LOG] time 03:11:50.226 :: org.flowplayer.audio::AudioProvider : TRCK: 1
[LOG] time 03:11:50.227 :: org.flowplayer.audio::AudioProvider : TCON: Indie
[LOG] time 03:11:50.228 :: org.flowplayer.audio::AudioProvider : TALB: Boxer
[LOG] time 03:11:50.228 :: org.flowplayer.audio::AudioProvider : TPE1: The 
National
[LOG] time 03:11:50.229 :: org.flowplayer.audio::AudioProvider : TIT2: Fake 
Empire
[LOG] time 03:11:50.231 :: org.flowplayer.audio::AudioProvider : dispatching 
START
[LOG] time 03:11:50.261 :: org.flowplayer.audio::AudioProvider : onId3(), 
_started == false
[LOG] time 03:11:50.262 :: org.flowplayer.audio::AudioProvider : current 
metadata
[Array] 
[Object] 
[String] TYER = 2007
[Number] duration = 205.1134693877551
[String] TPE1 = The National
[String] TRCK = 1
[String] TCON = Indie
[String] TALB = Boxer
[String] TENC = Exact Audio Copy   (Secure mode)
[String] TIT2 = Fake Empire

When going from an item with a coverimage to an item without one it stays in 
the screen.

Original comment by electrot...@gmail.com on 18 Jun 2012 at 5:15

GoogleCodeExporter commented 9 years ago
1) image is being cleared now when changing playlist items, its reusing the 
previous loaded image display,  no idea how long that was like that for. 
2) still some issues im seeing replaying and will check metadata. 

Original comment by dani...@electroteque.org on 29 Jun 2012 at 3:35

GoogleCodeExporter commented 9 years ago
replay is fine, metadata is fine, however the duration tracker is now stopping 
the next clip because its using the previous time initially ??

Original comment by dani...@electroteque.org on 29 Jun 2012 at 3:54

GoogleCodeExporter commented 9 years ago
now its only replaying the last clip in the playlist :)

Original comment by dani...@electroteque.org on 29 Jun 2012 at 6:57

GoogleCodeExporter commented 9 years ago
gotcha it is not dispatching a metadata event if its cached and doesnt need to 
estimate the duration. the clip metadata is filled which is available in 
onstart so dispatching beforehand is simple however the id3 event is triggered 
twice so needs to be trapped. 

Original comment by dani...@electroteque.org on 29 Jun 2012 at 7:32

GoogleCodeExporter commented 9 years ago
that issue is solved apart from the fact the playlist is replaying the last 
clip now, the plugin was also dispatching finish hence going to the next item 
in the playlist was stopping. 

Original comment by dani...@electroteque.org on 29 Jun 2012 at 7:54

GoogleCodeExporter commented 9 years ago
really tough one, it is randomly not rewinding the playlist :) once that is 
figured out this is good to go. 

Original comment by dani...@electroteque.org on 29 Jun 2012 at 8:39

GoogleCodeExporter commented 9 years ago
ok that is fixed up. 

1) when not fully cached, metadata is sent initially and then again once the 
duration has been updated
2) when fully cached, it will dispatch the metadata correctly also. 

Original comment by dani...@electroteque.org on 29 Jun 2012 at 10:15

GoogleCodeExporter commented 9 years ago
https://dl.dropbox.com/u/3394987/flowplayer.audio-3.2.9.zip please try this i 
think its all good now. 

Original comment by dani...@electroteque.org on 29 Jun 2012 at 10:17

GoogleCodeExporter commented 9 years ago
now isn't updating the duration of the second playlist item no id3 event 
re-sent, very random ! 

Original comment by dani...@electroteque.org on 29 Jun 2012 at 12:25

GoogleCodeExporter commented 9 years ago
id3 v1 tags are at the end of the file to general demo has it at the head and 
tail, crazy. files with just v2 are at the header. need to change things to get 
the duration updated correctly once the file is fully buffered. from the looks 
of it jwplayer does not try to update the duration after attempting the initial 
check. 

Original comment by dani...@electroteque.org on 29 Jun 2012 at 12:41

GoogleCodeExporter commented 9 years ago
now the second demo file does not dispatch id3 or complete events when 
replaying if tested alone ;)

Original comment by dani...@electroteque.org on 29 Jun 2012 at 1:03

GoogleCodeExporter commented 9 years ago
https://dl.dropbox.com/u/3394987/flowplayer.audio-3.2.9.zip

better, that demo mp3 is unreliable it does indeed have id3 tags on the head 
and tail, possible to use a different one ? 

all metadata events should work now in every different possible mode tests 
which is many. 

Original comment by dani...@electroteque.org on 29 Jun 2012 at 1:45

GoogleCodeExporter commented 9 years ago
I removed the id3v1 tags from 
http://releases.flowplayer.org/data/fake_empire.mp3 and will do the same for 
http://flowplayer.org/media/data/fake_empire.mp3 (which hopefully catches all 
instances)

I still think it's good if flowplayer can handle/ignore id3v1 tags - as we can 
see these crop up really a lot.

Original comment by blacktrashproduct on 1 Jul 2012 at 3:02

GoogleCodeExporter commented 9 years ago
https://github.com/flowplayer/site/issues/537

Original comment by blacktrashproduct on 1 Jul 2012 at 3:06

GoogleCodeExporter commented 9 years ago
It will fire at the end for idv1 but not do anything, will just return, pretty 
much just checks that start has dispatched.

There is like 5 different places start and metadata needed to be dispatched I 
think , I think its all covered now, let me know if there is still a problem. 

Original comment by dani...@electroteque.org on 2 Jul 2012 at 3:24

GoogleCodeExporter commented 9 years ago
Yet another problem are id3v2 version _2_ tags, apparently still created by 
iTunes; see: http://flowplayer.org/forum/8/101589#post-101628

id3v2.2 is considered obsolete, but with iTunes still doing this, it will crop 
up quite often. Docs are updated though:
https://github.com/flowplayer/site/commit/db3e749d2b2d2f5c2dea83829793878e848320
c5

See: http://id3.org/Developer_Information
supported id3v2.3: http://id3.org/d3v2.3.0
obsolete id3v2.2: http://id3.org/id3v2-00 (using 3-letter tags)

Original comment by blacktrashproduct on 2 Jul 2012 at 2:13

GoogleCodeExporter commented 9 years ago
id3 2.2 via itunes will not trigger the id3 data event. ive sent how to 
reconfigure the version within itunes to a few people. perhaps only 2.3 and 2.4 
will only work ? 

Original comment by dani...@electroteque.org on 4 Jul 2012 at 1:53

GoogleCodeExporter commented 9 years ago
That's how I updated the docs: id3v2.3 and higher is required.

What is unclear is whether the mere presence of id3v1 tags (in conjunction with 
id3v2.3 tags) confuses the parser. It seems to work fine with e.g. this file:
http://media.blacktrash.org/atap.mp3
but I seem to remember cases where this caused problems.

Original comment by blacktrashproduct on 4 Jul 2012 at 2:09

GoogleCodeExporter commented 9 years ago
idv1 tags retrigger the id3 data event at the end of the file once its 
downloaded. It prevents anything happening there as the start has dispatched 
already so no issues. That took me  while to work out why that was happening, 
but now we know ;)

Original comment by dani...@electroteque.org on 4 Jul 2012 at 11:43

GoogleCodeExporter commented 9 years ago
all good now to close ? 

Original comment by dani...@electroteque.org on 6 Jul 2012 at 4:52

GoogleCodeExporter commented 9 years ago
closing this and hopefully all fixed now :(

Original comment by electrot...@gmail.com on 28 Jul 2012 at 11:19

GoogleCodeExporter commented 9 years ago

Original comment by electrot...@gmail.com on 28 Jul 2012 at 11:20