Hi,

Simon Baxter wrote:

...

Below you'll find output of VDR on console. Do you also see the StillPicture line?

mp3: heartbeat buffer=0 now=1540 mp3: heartbeat buffer=572 now=1541 mad: lost sync 43474154 6e697972 TAGCryin mad: skipping over ID3 tag mp3: eof or error mp3: stopping play mp3: scale stats clipped=0 peak_clip=0.000000 peak=0.985417 norm: stats tot=23334912 lim=9761/0.042% clip=177/0.001% peak=1.253 mgr: next -> 1 mp3: playing next mp3: starting play mgr: playing a-ha - Minor Earth Major Sky.mp3 mp3: found song level=0.332000 peak=1.106800 norm: gain=0.753012 dogain=1 dolimit=0 (target=0.250000 level=0.332000 peak=1.106800) mp3: isStream=0 levelgood=1 haslevel=1 image: checking image for a-ha - Minor Earth Major Sky.mp3 image: check /data/mp3/a-ha - Minor Earth Major Sky.jpg image: found image: loading image /data/mp3/a-ha - Minor Earth Major Sky.jpg image: cached StillPicture: 0x86444d8, 16081 mp3-ctrl: mode change detected mp3: heartbeat buffer=0 now=1543 mp3: write delayed 2540 ms mp3: heartbeat buffer=572 now=1544 mp3: heartbeat buffer=2048 now=154

You might be on to something there. Below is two instances of loading an image - one cached, the other not. Both end up with MAD losing sync..

mp3: play mp3: player active true done mp3-dvb: using DVB output mp3: heartbeat buffer=0 now=2730 mp3: starting play mgr: bgr-scan -> throttle (64657) mgr: playing 03 - Daughter.mp3 mgr: background scan throttled mp3: isStream=0 levelgood=1 haslevel=0 mp3: heartbeat buffer=0 now=2731 image: checking image for pearljam/03 - Daughter.mp3 image: check /mnt/music/pearljam/03 - Daughter.jpg image: check /mnt/music/pearljam/03 - Daughter.png image: check /mnt/music/pearljam/03 - Daughter.gif image: check /mnt/music/pearljam/cover.jpg image: found image: loading image /mnt/music/pearljam/cover.jpg image: cached

vvvvv looks different to mine vvvvv

mad: lost sync 03334449 00000000 ID3 mad: skipping over ID3 tag

^^^^^ looks different to mine ^^^^^

mp3-ctrl: mode change detected

image: check /mnt/music/Oasis/Definitely Maybe/09 - Digsy's Dinner.png image: check /mnt/music/Oasis/Definitely Maybe/09 - Digsy's Dinner.gif image: check /mnt/music/Oasis/Definitely Maybe/cover.jpg image: found image: loading image /mnt/music/Oasis/Definitely Maybe/cover.jpg image: not cached image: convert queued image: using static default image image: convert started /mnt/music/Oasis/Definitely Maybe/cover.jpg -

...

/video/vdr-1.3.33/plugins/cache/image/mp3//mnt/music/Oasis/Definitely

Maybe/cover.jpg.mpg mad: lost sync 03334449 00000000 ID3 mad: skipping over ID3 tag mp3: new input sample rate 44100 image: still queued image: still queued image: still queued mp3: heartbeat buffer=2048 now=2700 image: convert finished image: loading image /mnt/music/Oasis/Definitely Maybe/cover.jpg image: cached

At this point, you've reached the state of the previous example.

Neither have the 'StillImage' message.

Any ideas???

Do you run vdr-xine with option -q (quiet)?

As there is only a single location where the mp3 plugin calls DeviceStillPicture(), you really should get this StillImage message. Maybe you should add a few debug messages to player-mp3.c.

What's your CPUs load when playing mp3 files, converting an image?

Does it take extraordinary long to load a converted image?

Bye.

Hi,

Simon Baxter wrote:

...

As there is only a single location where the mp3 plugin calls DeviceStillPicture(), you really should get this StillImage message. Maybe you should add a few debug messages to player-mp3.c.

I've added a couple of markers : next: if(!pframe && playing && !imageValid && imageCheck<time_ms()) { unsigned char *mem; int len; printf("mp3:SBB Marker 1 "); imageCheck=time_ms()+250; imageValid=playing->Image(mem,len); if(mem) { if(playindex) usleep(80*1000); // stillpicture ioctl freezes without this printf("mp3:SBB Marker 2 "); DeviceStillPicture(mem,len); free(mem); } }

and can see them coming up in the logs : mp3: play mp3: player active true done mp3-dvb: using DVB output mp3: heartbeat buffer=0 now=1932 mp3: starting play mgr: bgr-scan -> throttle (33087) mgr: playing 02 - To Love Somebody.mp3 mp3: isStream=0 levelgood=1 haslevel=0 mp3:SBB Marker 1 image: checking image for yesterday once more/02 - To Love Somebody.mp3 image: check /video/vdr-1.3.33/plugins/mp3s/yesterday once more/02 - To Love Somebody.jpg image: check /video/vdr-1.3.33/plugins/mp3s/yesterday once more/02 - To Love Somebody.png image: check /video/vdr-1.3.33/plugins/mp3s/yesterday once more/02 - To Love Somebody.gif image: check /video/vdr-1.3.33/plugins/mp3s/yesterday once more/cover.jpg image: found image: loading image /video/vdr-1.3.33/plugins/mp3s/yesterday once more/cover.jpg image: cached mgr: background scan throttled mp3:SBB Marker 2 mad: lost sync 03334449 00000000 ID3^C mad: skipping over ID3 tag mp3: new input sample rate 44100 mp3: heartbeat buffer=0 now=1933 mp3-ctrl: mode change detected mp3: heartbeat buffer=572 now=1934 mp3: heartbeat buffer=0 now=1935 mp3: heartbeat buffer=2048 now=1936 mp3: heartbeat buffer=2048 now=1937 mp3: heartbeat buffer=572 now=1938 mp3: heartbeat buffer=0 now=1939 mp3: heartbeat buffer=2048 now=1940 mp3: heartbeat buffer=572 now=1941

All this shows me is that the DeviceStillPicture is probably executing, just not logging.

Please locate the follwing function in xineDevice.c and add an additional marker like above.

void cXineDevice::StillPicture(const uchar *Data, int Length) { xfprintf(stderr, "StillPicture: %p, %d\n", Data, Length);

Bye.

Hi,

Simon Baxter wrote:

Thanks - put the marker in. Again, nothing unexpected.

void cXineDevice::StillPicture(const uchar *Data, int Length) { xfprintf(stderr, "StillPicture: %p, %d\n", Data, Length); printf("xine:SBB Still Picture Marker 1 "); if (0)

image: loading image /mnt/music/Supertramp/The Very Best Of Supertramp/cover.jpg image: not cached image: convert queued image: using static default image mp3:SBB Marker 2 xine:SBB Still Picture Marker 1 image: convert started /mnt/music/Supertramp/The Very Best Of Supertramp/cover.jpg -

...

/video/vdr-1.3.33/plugins/cache/image/mp3//mnt/music/Supertramp/The

Very Best Of Supertramp/cover.jpg.mpg mad: lost sync 03334449 00000000 ID3^C mad: skipping over ID3 tag

No mention again of StillPicture....??????????

Well, the difference is that your message goes to stdout while vdr-xine's messages go to stderr.

When you run vdr, is there anything that redirects stderr for example to /dev/null, e. g. something like the following line?

vdr ..... 2>/dev/null

Concerning the example mp3's you've sent me: I've renamed them as mentioned below in the log messages to match the cover image mpegs you've sent me some time ago, which were renamed accordingly yet.

I too get the lost sync message, but the images still appear perfectly. Strange is that I don't get this message for any mp3 file from my brother's library. I know that there are several versions for mp3 tags, so either libmad doesn't understand the version your software creates or your software simply does it wrong. But I'm no mp3 expert ;-)

I'll now try to reproduce this issue on a different machine. Please stay tuned ;-)

mp3: heartbeat buffer=572 now=3277 mp3: heartbeat buffer=2048 now=3278 mp3: heartbeat buffer=0 now=3279 mp3: heartbeat buffer=2048 now=3280 mad: lost sync 44474154 68677561 TAGDaugh mad: skipping over ID3 tag norm: new volumen level=0.228871 peak=1.004627 cache: updating infos for /data/mp3/a-ha - Crying In The Rain.mp3 mp3: eof or error mp3: stopping play mp3: scale stats clipped=3 peak_clip=0.004666 peak=1.000000 mgr: next -> 1 mp3: playing next mp3: starting play mgr: playing a-ha - Minor Earth Major Sky.mp3 mp3: isStream=0 levelgood=1 haslevel=0 image: checking image for a-ha - Minor Earth Major Sky.mp3 image: check /data/mp3/a-ha - Minor Earth Major Sky.jpg image: found image: loading image /data/mp3/a-ha - Minor Earth Major Sky.jpg image: cached StillPicture: 0x93499b8, 16081 mp3-ctrl: mode change detected mad: lost sync 03334449 00000000 ID3 mad: skipping over ID3 tag mp3: heartbeat buffer=0 now=3283 mp3: write delayed 2567 ms mp3: heartbeat buffer=0 now=3284 mp3: heartbeat buffer=0 now=3285 mp3: heartbeat buffer=0 now=3286

Bye.

Hi,

Stefan Huelswitt wrote:

...

...

Very Best Of Supertramp/cover.jpg.mpg mad: lost sync 03334449 00000000 ID3^C mad: skipping over ID3 tag

I too get the lost sync message, but the images still appear perfectly. Strange is that I don't get this message for any mp3 file from my brother's library. I know that there are several versions for mp3 tags, so either libmad doesn't understand the version your software creates or your software simply does it wrong. But I'm no mp3 expert ;-)

The "lost sync" message means that the mp3 decoder has detected something in the stream, which can't be decoded. This can be a ID3 tag but some other garbage too. The next message "skipping over ID3 tag" means that a ID3 tag was recognised.

Hhm, though it's strange that I don't get these messages for my brother's files although they contain ID3 tags too, but maybe a different version.

The messages are not related to the image processing in any way.

That's right.

@Simon: I've tried to reproduce this issue on my other system but I can't reproduce it. My last resort would be to write the stream data which input_vdr receives into a file for further debugging.

How are your programming skills? Do you think you can manage this on your own?

Bye.