Am Sonntag, 19. August 2007 16:44:15 schrieben Sie:
> Uwe Bugla <uwe.bugla@...> writes:
> > Yes, earlier versions of xine-lib worked _purrrrrrfect_, in so far it
> > _is_ a regression in xine-lib, definitely!
> Which version did work for you correctly? I'd suggest that you hg bisect
> in order to find the exact hg commit which caused the regression.
Same problem as with kernel bugs:
a. I have a very slow Internet connection. :(
b. I am not _too familiar_ with bisecting at all. :(
But I will send in a verbose debug log plus a screenshot after a while, as
proposed by Darren.
> Since I don't use xine for dvb, I fear that I cannot help you with that.
> > I am working with a small not yet released self-built TCL/TK/Iwidgets-4.0
> > project using time-shifting: dvbstream records something, then the system
> > sleeps a couple of seconds, then the player starts to play back the
> > recorded material. That way recording engine and playback engine _race_
> > against each other (like two cars - time-shifted).
> sounds interesting. Please CC me when you release your first version!
Sure! I am developing it primarily for and under Debian, as I am _not_ too
positive about other distros like SuSE or RedHat :)
In so far it would be a pleasure if it became part of one of the Debian
It will feature:
a. a very practical dish tuning transforming the necessary parameters into
b. DVB network broadcasting _plus_ client playback _and_ recording (which is
only possible with mplayer right now and which kaffeine cannot do at the
moment - only client playback, no recording).
c. Basic principle of the project is: To be a counter-part towards vdr:
_One_ simple budget card in a server, broadcasting to many workstations
without artefacts and other errors
d. a DVB list scan which is more accurate than the conventional DVB-scan ever
was (linuxtv maintainers _are_ a disease).
e. timer recording, manual recording, two videotext apps plus EPG
f. a tiny little channel list editor
g. support for DVB-S _and_ DVB-T
h. a trilingual language interface (German, English, French - my three core
languages, hoping that there will be lots of more translations once the
project is to be found in the internet)
i. automatic filtering of test and other junk channels (those with invalid
names for instance)
I've done dozens of recordings of rare TV jewelry (concerts, documentations,
other interesting historical rare stuff). NO crashes, not even one, 100 %
stable and reliable.
Result is a very nice archive of TV and Radio jewelry in DVD / or MP3 quality.
> > If the sleep timing is too short, the whole thing dies after a couple of
> > minutes (usually two or three - but never in this life after half an
> > hour!).
> > As a consequence I can definitely exclude the timing issue as possible
> > case for the breakdown.
> > Thus the regression in xine-lib is the only possible reason for the
> > crash, at least in my perception.
> > See: If you are recording real nice rarities (like the legendary
> > Rockpalast gig of _Grateful Dead_ in 1981 f. ex. last night), and the
> > recording breaks down after a while that really bothers you as some
> > events do _not_ appear too often on TV - especially the legendary jewelry
> > that is being broadcasted once in ten or twenty years :(
> I'm sorry :(
No sweat please :) I was forward looking enough to see the xine bug by testing
stuff before the concert broadcast started. So I used mplayer as playback
engine, and everything is fine so far...... :(
The legendary Dead gig is being cut and prepared for DVD burning right at the
moment. I'm die-hard Dead fan, you know.
But if you're not experienced enough or forward looking enough those crash
experiences can be really painful.
And above that, as I stated already, lots of other software is dependent on
> >> > Please do your best to make that lib stable, so that such an accident
> >> > does not happen again.
> >> Hints how to do that would help. Offer for help as well.
> > Ain't no programmer, but I do my best to describe the issues as precise
> > as possible :)
> > Let's try to activate the xine maintainers and developers :)
> Yes, lets see if someone of them can comment on this.
> > I guess xine-lib was moved from experimental to unstable in a far to
> > early state, wasn't it?
> No, it was in experimental because the new version was not fit for the
> 'etch' release. Since lenny is not frozen yet, new upstream versions are
> fine for 'unstable'.
a. What is called _unstable_ at Debian is usually _very stable_ in practice.
In so far that xine-lib bug is a bit _tasty_ .
b. The only reason I use the unstable _sid_ branch is that the _lenny_ branch
has not been updated for almost 3 months, you know.
c. Not only as DVB user you need fresh kernels above that.
P. S.: Sorry, that was a long rant :)