Re: libdvdread: Can't seek to block 256

H}kan Hjort <[email protected]>
Newsgroups gmane.comp.video.ogle.user
Message-ID <[email protected]>
Tue Dec 09 2003, Felix Kurth wrote:
> 
> The shit happens in device.c  from libdvdcss-1.2.8
> on line 425
> static int libc_seek( dvdcss_t dvdcss, int i_blocks )
> i_blocks==256
> dvdcss seems valid.
> 
> it calls on line 435 
> i_seek = lseek( dvdcss->i_read_fd,
>  		                    (off_t)i_blocks * (off_t)DVDCSS_BLOCK_SIZE, SEEK_SET );
> where 
> dvdcss->i_read_fd == 3
> DVDCSS_BLOCK_SIZE=2048
> SEEK_SET==0
> this returns -1
> 
> in the strace i read 
> 
> _llseek(3, 524288, 0xbfffc4f0, SEEK_SET) -1 EINVAL (Invalid argument)
> 
> evaluating  "0xbfffc4f0" to decimal returns "-1073756944"
> (is this a valid value  ?)
> 
> evaluating 256*2048 returns "524288" or hex "80000"
> 
Ok so that is the same as the 'high' part of the _llseek call.
It should have been passed in the low word and the high should
have been zeroed.  Looks like a prototype and/or compiler bug.
Not 100% sure that the code is ok though.

> what happens in lseek ? Why comming from 80000 to -1073756944 ?
>  what can i do ? Compile glibc with -q and debug deeper ?
> 
Na...

Try and add the following to this function

  off_t pos = (off_t)i_blocks * (off_t)DVDCSS_BLOCK_SIZE;
and pass that to the lseek call.

You could try an print that also
fprintf(stderr, "off_t pos is %ll\n", pos);

> man _llseek
> says
> int  _llseek(unsigned int fd, unsigned long offset_high, unsigned long 
> offset_low, loff_t *result, unsigned int whence);
> EINVAL: whence is invalid.
> 
> but the call in the strace has only 4 parameters, no "whence" is set ?
> (my glibc ver is 2.3.2)
> 
Did you use a binary distrubution for libdvdcss?  If so are you sure
that was compiled agains the same version of glibc ?
If you used a binary package you could try and compile and install
libdvdcss from source.

> How can i make an executable link against a lib in an other then the
> default location ?
> I wont install a self-compiled glibc on my system since i dont want to break 
> it.
> 
That way lies ruin... we should be able to solve this some other way.

-- 
Håkan Hjort
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.