kino-1.0.0-alt1?

On Thu, Jun 28, 2007 at 10:43:20PM -0400, Gene Heskett wrote:
> I am enough of a masochist that I build my own kernels,
> currently running 2.6.22-rc6-cfs-v18, and I test new releases
> of amanda as they come out, building them from tarballs, but
> livna has tested my tolerance for both extra deps that then
> demand an exclusively livna only install, and/or missing
> dependencies such as this, and found it wanting, sorry.  atrpms
> and freshrpms don't seem to clash with core near as often.

Gene, I can suggest you to try out this:
ftp://beta.altlinux.ru/desktop/cd-20070628.iso

It doesn't contain kino (I've asked to include it in the next
beta DVD a minute ago) but there's stable build which I do use
at home (and my parents even more heavily), as a maintainer.

There's also decent ffmpeg build available in 4.0/branch, and
our repositories are covered with unresolved symbols testing
so there's rarely headache on non-trivial dependency botches.
Usually if one manages to mix up e.g. 2.4 and 3.0, sort of.

Adding 4.0/branch and installing kino from it should be like:

cat >> /etc/apt/sources.list << EOF
rpm [updates] ftp://ftp.altlinux.org/pub/distributions/ALTLinux/4.0/branch i586 classic
rpm [updates] ftp://ftp.altlinux.org/pub/distributions/ALTLinux/4.0/branch noarch classic
rpm ftp://ftp.altlinux.org/pub/people/boyarsh/repo i586 hasher
EOF
apt-get update
apt-get install kino

Re: kino-1.0.0-alt1?

On Wednesday, 04 July 2007 at 23:46, Michael Shigorin wrote:
[...]
> I'm sorry to admit that I'm constantly harsh to Fedora project
> attitude "users are testers"

There's no such attitude.

> but then they're not warning enough that USERS ARE TESTERS.

Everyone was invited to test the new features during testing phase. If it
worked for the maintainers and no bugs were reported then, how could they
have known know that it didn't work for someone else?

> Here at ALT, users are users and often
> colleagues, but not desperate testers or someone's puritanic mood
> hostages.  So we do ship and set up binary drivers for cards that
> practically do need them

... sacrificing freedom for pragmatism. It's your choice. Fedora chose to
be completely free and is following that choice to the letter. Having said
that, it's common knowledge that you can get the missing parts from Livna,
should you need them.

> (while maintaining free drivers as an
> option in best shape possible).  And we do have working kino. :)

Kino from Livna is working fine. I've had success reports from users, too.

Regards,
R.

Re: kino-1.0.0-alt1?

On Wednesday 04 July 2007, Michael Shigorin wrote:
>On Thu, Jun 28, 2007 at 10:43:20PM -0400, Gene Heskett wrote:
>> I am enough of a masochist that I build my own kernels,
>> currently running 2.6.22-rc6-cfs-v18, and I test new releases
>> of amanda as they come out, building them from tarballs, but
>> livna has tested my tolerance for both extra deps that then
>> demand an exclusively livna only install, and/or missing
>> dependencies such as this, and found it wanting, sorry.  atrpms
>> and freshrpms don't seem to clash with core near as often.
>
>Gene, I can suggest you to try out this:
>ftp://beta.altlinux.ru/desktop/cd-20070628.iso
>
>It doesn't contain kino (I've asked to include it in the next
>beta DVD a minute ago) but there's stable build which I do use
>at home (and my parents even more heavily), as a maintainer.
>
>There's also decent ffmpeg build available in 4.0/branch, and
>our repositories are covered with unresolved symbols testing
>so there's rarely headache on non-trivial dependency botches.
>Usually if one manages to mix up e.g. 2.4 and 3.0, sort of.
>
>Adding 4.0/branch and installing kino from it should be like:
>
>cat >> /etc/apt/sources.list << EOF
>rpm [updates] ftp://ftp.altlinux.org/pub/distributions/ALTLinux/4.0/branch
> i586 classic rpm [updates]
> ftp://ftp.altlinux.org/pub/distributions/ALTLinux/4.0/branch noarch classic
> rpm ftp://ftp.altlinux.org/pub/people/boyarsh/repo i586 hasher
>EOF

[OT] Re: kino-1.0.0-alt1?

PreScriptum: I'd better rant in some form of blog so relevant
part of it would get indexed/corrected by comments, but my
sorta-livejournal is Russian spoken.  If you care, be my friend
in private mail (proshu pana do poshty), let's not do /p vs i/
again. :)

<offtopic>

On Wed, Jul 04, 2007 at 11:59:01PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> > I'm sorry to admit that I'm constantly harsh to Fedora
> > project attitude "users are testers"
> There's no such attitude.

There is, in project overall.  Bleeding-edge software commitment
_is_ that attitude, and people are free to live with or without
it.

I respect your works but trust me (for different reasons: being
outside Fedora, having jumped off RHL back in 1999 or so,
following DJ's blog and reports from LKML regarding 2.6.21 in F7,
or being a humble maintainer for some 180 SRPMs in ALT): there is.

Those more experienced would wait for a bunch of updates to
release (e.g. an older person who would insist on rolling Fedora
into production for our clients but wouldn't actually reason that
or get hands greasy with handling problems: he thanked for F7 DVD
image promptly gotten to the office shortly after release but
noted that he doesn't jump ships before updates pile up).

Those even more experienced who aren't passionate for software

Re: [OT] Re: kino-1.0.0-alt1?

On Thursday, 05 July 2007 at 08:29, Michael Shigorin wrote:
[...]
> > It's your choice. Fedora chose to be completely free and is
> > following that choice to the letter. Having said that, it's
> > common knowledge that you can get the missing parts from Livna,
> > should you need them.
> 
> So, erm, why Fedora without Livna is largely considered unusable?
> (with additional repos being the first thing done by experienced
> and the first thing recommended to those lost with 2D or vesa,
> without mp3 or wmv; at least from what I observe for years)

Since Fedora is US-based, they can't ship all that stuff in the distro, nor
even officially recommend it (read: contributory infringement lawsuits).

> Why pretend You Are So Free when the very next door is Not
> Exactly Alive?  It's like being declared a no-smoker but then
> turning out to be paralized in the first place.
> 
> IIRC we did reject code that was happily included in some of
> PLF, Livna and pacman packages.  But we do include code that
> can be shipped and used with respect to copyright (software
> patents don't currently work in Russia or Ukraine), e.g. WMV3
> (aka Windows Media Video 9) support in ffmpeg.  We consider
> that practical for now and, well, honest.

I'm happy for you, but not every country's law bans software patents. If
Fedora were based in Ukraine or Poland, then we could have MP3, DVD
playback, and all the multimedia stuff that is patented in the US. Sadly,
the reality is different. So instead of making itself vulnerable to

Re: [OT] Re: kino-1.0.0-alt1?

On Fri, Jul 06, 2007 at 07:19:23PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> So instead of making itself vulnerable to lawsuits, Fedora
> chose not to ship that stuff at all. I'm sure you can
> understand that.

Definitely, but that's not an excuse in my eyes.  When folks
needed to obviate the foolishness of US officials deeds in
crypto export field, they just hosted projects elsewhere.

So I'm naturally proposing better non-US distros to folks
worldwide (we even happen to have a user from Pakistan :).
If anyone ever feels frustrated enough with US policies
we're open for developers as well, although that would
set a precedent yet. (heck, I've heard of folks who moved
to Moscow or Siberia from US to get rid of that!)

> > > Kino from Livna is working fine. I've had success reports
> > > from users, too.
> > Glad to hear that.  Folks doing those repos could try and
> > setup a mailing list to coordinate soname/ABI changes and
> > probably interpackage dependencies (I'd suggest "rolling
> > together" but guess they do have reasons not to), could you
> > pass this paragraph there?
> Work on a common merged 3rd party repository for Fedora is
> progressing slowly. We are painfully aware of all the relevant
> issues.

Judging on Fedora, guess not all.  They've painfully waded couple
of years ago through dependency issues that were solved ca. 2002
or 2003 in ALT (mostly due to introducing apt which uncovered

kino-1.0 will not start

I try to start Kino 1.0 from the terminal, and it hangs at the
splash screen.  The terminal output is pasted in below.

I imagine that I should supply some further system information -- what
information would be relevant?  I am running Ubuntu 7.10, with kernel
2.6.22.

Thanks,
Hans

********************

# kino
> help language code en

***MEMORY-WARNING***: [8656]: GSlice: g_thread_init() must be c
alled before all other GLib functions; memory corruption due to
 late invocation of g_thread_init() has been detected; this pro
gram is likely to crash, leak or unexpectedly abort soon...
> Kino Common being built
> Creating page editor
> Creating Capture Page
> Creating Export Page
> Creating Export1394 Page
> Creating ExportAVI Page
> Creating ExportStills Page
> Creating ExportAudio Page
> Creating ExportMJPEG Page
/usr/share/kino/scripts/dvdauthor/dvdauthor-k3b.sh
/usr/share/kino/scripts/dvdauthor/none.sh

Re: kino-1.0 will not start

Hans also posted to the forum, which I already replied to:

http://www.kinodv.org/dcforum/dcforum?az=show_topic&forum=101&topic_id=2844&mesg_id=2844

On Sunday 08 July 2007, Hans Halvorson wrote:
> I try to start Kino 1.0 from the terminal, and it hangs at the
> splash screen.  The terminal output is pasted in below.
>
> I imagine that I should supply some further system information -- what
> information would be relevant?  I am running Ubuntu 7.10, with kernel
> 2.6.22.
>
> Thanks,
> Hans
>
> ********************
>
> # kino
>
> > help language code en
>
> ***MEMORY-WARNING***: [8656]: GSlice: g_thread_init() must be c
> alled before all other GLib functions; memory corruption due to
>  late invocation of g_thread_init() has been detected; this pro
> gram is likely to crash, leak or unexpectedly abort soon...
>
> > Kino Common being built
> > Creating page editor
> > Creating Capture Page
> > Creating Export Page

mpg1394grab and data loss

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
Kino-dev mailing list
Kino-dev <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kino-dev

Re: mpg1394grab and data loss

On Monday 09 July 2007 7:59:43 am Paul McEnery wrote:
> I have chosen this list for my question because the author of mpg1394grab
> appears to be a key developer of Kino, and mpg1394grab is recommended for
> capturing HDV content on the website. Sorry of this is not the place, but I
> cant think of a better place to ask it...

I wrote it rather ad hoc for MicroMV, but I do not recommend it for HDV.

> Over the weekend, I captured HD video from my Sony HDR-HC1 camcorder and
> tried to redirect the output directly to a USB2.0 attached hard drive. It
> appears that the hard drive was not quite fast enough to keep up with the
> stream and the video came out with loads of artefacts and was pretty much
> unwatchable.

mpg1394grab has no buffering, which is why I not recommend it

> I retried the capture writing directly to an internal drive. This appeared
> to be more successful. Obviously disk speed plays an important role. The
> thing that concerns me is that when redirecting stdout, I get no error
> messages if the disk is unable to keep up with the required rate of data
> transfer. During the first capture I ended up with a 4GB file, while the
> second capture produced a 12GB file. Obviously I had no error messages
> during either of the captures.
>
> What I would like to know is, how can I be sure that every bit of data that
> comes from the 1394 port IS written to the hard drive? I.e. Say someone
> fires up firefox while I am capturing. It would appear that if the system
> is busy, I have no guarantee that ALL of the data will be written to disk.

this is another reason--poor feedback. Again, it was an ad hoc program--I did 
not even own a MicroMV camera--not as a full solution.

> As an aside, I thought of piping the output from mpg1393grab to something
> like dd, but obviously buffering would become an issue.
>
> Has anyone else encountered this issue before, and are there any well known
> remedies?

The solution is dvgrab 3.0:

http://www.dennedy.org/index.php?option=content&task=view&id=84&Itemid=2

--

-- 
+-DRD-+

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/