Closed GoogleCodeExporter closed 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
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
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
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
now its only replaying the last clip in the playlist :)
Original comment by dani...@electroteque.org
on 29 Jun 2012 at 6:57
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
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
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
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
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
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
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
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
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
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
https://github.com/flowplayer/site/issues/537
Original comment by blacktrashproduct
on 1 Jul 2012 at 3:06
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
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
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
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
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
all good now to close ?
Original comment by dani...@electroteque.org
on 6 Jul 2012 at 4:52
closing this and hopefully all fixed now :(
Original comment by electrot...@gmail.com
on 28 Jul 2012 at 11:19
Original comment by electrot...@gmail.com
on 28 Jul 2012 at 11:20
Original issue reported on code.google.com by
blacktrashproduct
on 1 Jun 2012 at 11:35