| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
According to bug 1773769, this breaks foo->open().
The fix (as used in Ville Skyttä's patch, which doesn't cover all cases) is
to replace this with (foo->open)().
This patch was generated using
sed -i -re 's/(([[:alnum:]_]+(->|\.))+open) ?\(/(\1) (/' `grep '[>.]open \?(' include -rIl`
One change (in a comment) is not committed.
|
|
|
|
Thanks to Harald Sitter from Amarok team for reporting a testcase.
|
|
|
|
If there's no signal, the tuner never goes to FE_TIMEDOUT. Add a separate
timeout, to prevent xine waiting forever in these situations.
|
|
We have seen input_rtp lock up in use, and traced the problem to the separate
tail/head locks on the input buffer. Reduce to a single lock, increasing lock
contention between the reader and the writer, but removing the previous
deadlock risk.
Also use select() before recv(), to ensure that we never wait forever for
packets (e.g. if we're trying to receive a multicast stream, but an
administrator has blocked all multicast packets to the device - iptables -A
INPUT --dst 224.0.0.0/4 -j DROP induces this failure for testing).
|
|
Add a configuration option, to let input_v4l users select their local TV
standard.
|
|
Make the DVB GUI configurable by config entry, for kiosk applications
|
|
|
|
|
|
|
|
|
|
|
|
Solaris definitions (1.2 branch commit).
|
|
Solaris definitions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Inspired by a patch by Albert Lee.
|
|
|
|
|
|
|
|
Hopefully, I've applied all of the $(LTLIBINTL) changes correctly...
|
|
|
|
|
|
|
|
|
|
SYNC string in the read data; if found, send a XINE_EVENT_UI_CHANNELS_CHANGED event, so that the frontend can go read the new metadata.
|
|
|
|
|
|
Some plugins may have been missed due to them not being built here.
|
|
|
|
read() function, and declare a new buf variable in the function as needed.
|
|
buf parameter, so that any kind of variable can be passed through it.
|
|
|
|
|
|
Hi, I've been tracking down a very odd bug this afternoon. As it turns
out it is caused by enabling xine's mmap() support for the input_file.c.
I'm running 32 bit linux 2.6.21. The file in question is 0x10e4da000
bytes long (you can probably guess what kind of bug this is by now :)
Anyway, the issue stems from the definition of mmap():
void *mmap(void *start, size_t length, int prot, int flags, int fd,
off_t offset);
compare this to the definition of st_size in struct stat:
off_t st_size; /* total size, in bytes */
On my machine (in input_file.c) sizeof(size_t) ==4, whilst
sizeof(off_t) == 8. However the compiler doesn't generate a warning
when the following is done in xine's code:
if ( (this->mmap_base = mmap(NULL, sbuf.st_size, PROT_READ,
MAP_SHARED, this->fh, 0)) != (void*)-1
So it silently truncates the upper part of the length. Obviously you
cannot mmap() a file that large into (32 bit) memory anyway, but as it turns
out, mmapping() 0xe4da000 succeeds, which causes... problems.
The patch (against xine-lib 1.1.6) does two things:
* Check that the length will not be truncated, while still allowing
for mmap()s of large files under 64 bit OSes.
* A correctness fix: if mmap() fails, this->mmap_base will be set to
0xffffffff. Later on when the file is closed, this means it was
attempting to do munmap(0xffffffff).
|
|
|
|
development branche
Am Samstag, 26. Mai 2007 17:48 schrieb Darren Salt:
> Could you also try not reverting that and instead applying one or
> both of the attached patches? Both playback and eject need to be
> tested. You should use the drive's eject button, though there's no
> harm in also checking xine-lib's eject code.
Ok, here's a modified patch, a combination of your two patches, with a
little fix. It works fine here, pressing the vcd button on xine-ui
starts playing vcd's directly and when pressing the stop button, I can
eject the CD by pressing the eject button on the cd drive.
I hope it's ok for you.
--
Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/
| http://packman.links2linux.de/
Manfred | http://www.knightsoft-net.de
|
|
|
|
The current input_v4l in xine-lib 1.1.6 is inherently buggy (it will
deference an invalid pointer in extract_mrl if the MRL contains a V4L input
name or frequency).
|
|
The attached patch applies after my logging patches (I can regenerate if
needed).
demux_ts attempted to read packets from the input 200 times before
giving up. When playing a local file, this is harmless, as it will hit
EOF 200 times; however, input_dvb waits 5 seconds for packets on each
call to read, resulting in a 1000 second delay if tuning fails.
Remove the counting of input packets, and add a comment to read() in
input_plugin.h, to indicate that we expect inputs to try and return some
data when read() is called. This fixes the delay, and makes it clear to
future maintainers that they shouldn't expect to loop like this.
--
Simon Farnsworth
|
|
The three attached patches (against 1.1.6) each increase the amount of
debug logging in their respective components. We've found the extra
logging useful when trying to track down faults.
I've split this into three patches to make it easier to apply only some
of our changes.
--
Comments welcome,
Simon Farnsworth
|
|
|
|
Patch from Dmitri Fedortchenko <dimo <at> angelhill.net>, required
for upstream Totem bug:
http://bugzilla.gnome.org/show_bug.cgi?id=418316
|
