thoggen-devel — Discussions among developers (programmers, translators, artists, UI designers)

Re: [Thoggen-devel] thoggen

[Martin U. <ue...@ee...>]

Hi Tim,

> > I used to use thoggen once in a while and was a bit disappointed
> > to learn that it does not work anymore on modern distributions
> > because apparently stable interfaces and backwards compatibility 
> > are not cool anymore.
> 
> To be fair, sometimes you just have to replace old stuff that's not up
> to scratch. Don't think anyone will miss HAL..

Well, I obviously missed it when I tried to compile thoggen. I am not sure 
what demonstrates the sad state of Linux userspace better: That the API
was so bad that it had to be replaced already, or that they just dropped
it without providing some kind of backwards compatibility. I am already
scared of the day when Wayland will replace X11. 


> > Anyway, I simply ripped out the HAL stuff which makes thoggen
> > compile and work again - at least for me. The patch is attached.
> > Not sure what functionality has been lost though.
> 
> Did you forget to attach the patch by any chance?

I don't think so, but I will attach it inline this time.


> Functionality lost might be that you have to restart Thoggen to make it
> pick up an external DVD drive that you plug in. Not sure if it will
> detect you inserting a disc after you started it either.
> 
> I plan to port Thoggen over to 1.0 once this lands in GStreamer for dvd
> drives: https://bugzilla.gnome.org/show_bug.cgi?id=678402 (any day now).
> 
> > Or can someone recommend an alternative to thoggen which just
> > works?
> 
> Handbrake perhaps? I hear Christian also added DVD ripping features to
> Transmageddon recently, but not sure if it landed in a release yet.

I will take a look at it. But it has not been included
in Debian/Ubuntu so far.

Thank you,
Martin


> Cheers
>  -Tim
> 
> 
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> Thoggen-devel mailing list
> Tho...@li...
> https://lists.sourceforge.net/lists/listinfo/thoggen-devel


diff --git a/configure.ac b/configure.ac
index c200ae9..1c1015a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -293,37 +293,37 @@ AC_CHECK_HEADERS([gst/pbutils/pbutils.h], ,
 CFLAGS="$SAVED_CFLAGS"
 CPPFLAGS="$SAVED_CPPFLAGS"
 
-dnl ===== Check for libhal =====
-
-PKG_CHECK_MODULES(HAL, [hal >= $libhal_required],, [
-   AC_MSG_ERROR(
-   [
-    Cannot find hal library >= $libhal_required (libhal)
-                    
-    Please check the following:
-                    
-     * Do you have the libhal _development_ package installed?
-       (usually called hal-devel, libhal-devel, libhal-dev or similar)
-       If 
-           ls -l /usr/lib/pkgconfig/hal.pc
-       reports that the file does not exist, then you are missing
-       the development package. If you installed libhal from 
-       source, this point does not apply to you.
-
-     * Do you have libhal installed more than once, e.g. once 
-       from package and once from source? (if both 
-           ls /usr/lib/libhal.so
-       and
-           ls /usr/local/lib/libhal.so
-       show results, you need to fix your installation.
-                    
-     * Did you install libhal from source? If yes, you might need to
-       point pkg-config to the location of the hal.pc file by
-       doing something like
-          export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
-       and then running ./configure again.
-                    
-      ])])
+#dnl ===== Check for libhal =====
+#
+#PKG_CHECK_MODULES(HAL, [hal >= $libhal_required],, [
+#   AC_MSG_ERROR(
+#   [
+#    Cannot find hal library >= $libhal_required (libhal)
+#                    
+#    Please check the following:
+#                    
+#     * Do you have the libhal _development_ package installed?
+#       (usually called hal-devel, libhal-devel, libhal-dev or similar)
+#       If 
+#           ls -l /usr/lib/pkgconfig/hal.pc
+#       reports that the file does not exist, then you are missing
+#       the development package. If you installed libhal from 
+#       source, this point does not apply to you.
+#
+#     * Do you have libhal installed more than once, e.g. once 
+#       from package and once from source? (if both 
+#           ls /usr/lib/libhal.so
+#       and
+#           ls /usr/local/lib/libhal.so
+#       show results, you need to fix your installation.
+#                    
+#     * Did you install libhal from source? If yes, you might need to
+#       point pkg-config to the location of the hal.pc file by
+#       doing something like
+#          export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
+#       and then running ./configure again.
+#                    
+#      ])])
 
 dnl ===== Check for DBus Glib bindings =====
 
@@ -409,8 +409,10 @@ AC_SUBST([DVDREAD_LIBS])
 
 dnl === Do not use deprecated glib/gtk+ functions ===
 
-GLIB_CFLAGS="-DG_DISABLE_DEPRECATED $GLIB_CFLAGS"
-GTK_CFLAGS="-DG_DISABLE_DEPRECATED -DPANGO_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED $GTK_CFLAGS"
+#GLIB_CFLAGS="-DG_DISABLE_DEPRECATED $GLIB_CFLAGS"
+GLIB_CFLAGS="$GLIB_CFLAGS"
+#GTK_CFLAGS="-DG_DISABLE_DEPRECATED -DPANGO_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED $GTK_CFLAGS"
+GTK_CFLAGS="-DPANGO_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED $GTK_CFLAGS"
 
 if test "x$USE_PROFILING" = "xyes"; then
   CFLAGS="-pg $CFLAGS"
diff --git a/src/gst-plugins/th-pixbufsink.c b/src/gst-plugins/th-pixbufsink.c
index 231a2c4..40c909b 100644
--- a/src/gst-plugins/th-pixbufsink.c
+++ b/src/gst-plugins/th-pixbufsink.c
@@ -15,6 +15,8 @@
  *                                                                         *
  ***************************************************************************/
 
+#include <glib.h>
+
 #include "th-pixbufsink.h"
 
 #include <gdk-pixbuf/gdk-pixbuf.h>
diff --git a/src/th-device-pool.c b/src/th-device-pool.c
index a21880a..686bab0 100644
--- a/src/th-device-pool.c
+++ b/src/th-device-pool.c
@@ -33,7 +33,13 @@
 # include "config.h"
 #endif
 
+#define NOHAL
+
+#ifndef NOHAL
 #include <libhal.h>
+#else
+#include <assert.h>
+#endif
 
 #include <dbus/dbus.h>
 #include <dbus/dbus-glib-lowlevel.h>
@@ -114,6 +120,7 @@ static GObjectClass  *dp_parent_class;          /* NULL */
  *
  ***************************************************************************/
 
+#ifndef NOHAL
 #ifndef USE_NEW_DBUS_HAL_API
 static const LibHalFunctions disc_drive_hal_cb_funcs = 
 {
@@ -126,6 +133,7 @@ static const LibHalFunctions disc_drive_hal_cb_funcs =
 	dp_hal_device_condition_cb /* device condiiton         */
 };
 #endif /* USE_NEW_DBUS_HAL_API */
+#endif
 
 /***************************************************************************
  *
@@ -136,7 +144,11 @@ static const LibHalFunctions disc_drive_hal_cb_funcs =
 static ThDevicePool *
 hal_ctx_get_device_pool (LibHalContext *ctx)
 {
+#ifdef NOHAL
+	assert(0);
+#else
 	return TH_DEVICE_POOL (hal_ctx_get_user_data (ctx));
+#endif
 }
 
 /***************************************************************************
@@ -182,7 +194,11 @@ dp_reconnect_set_hal_ctx (ThDevicePool *pool, LibHalContext *ctx)
 	
 	if (ctx)
 	{
+#ifdef NOHAL
+		assert(0);
+#else
 		hal_ctx_set_user_data (pool->priv->hal_ctx, pool);
+#endif
 
 		for (l = pool->priv->trackers;  l;  l = l->next)
 		{
@@ -233,7 +249,11 @@ device_pool_instance_init (ThDevicePool *pool)
 
 #else
 
+#ifdef NOHAL
+	new_hal_ctx = NULL;
+#else
 	new_hal_ctx = hal_initialize (&disc_drive_hal_cb_funcs, TRUE);
+#endif
 
 #endif /* USE_NEW_DBUS_HAL_API */
 
@@ -277,6 +297,9 @@ device_pool_finalize (GObject *object)
 
 	if (pool->priv->hal_ctx)
 	{
+#ifdef NOHAL
+		assert(0);
+#else
 #ifndef USE_NEW_DBUS_HAL_API
 		if (hal_shutdown (pool->priv->hal_ctx) != 0)
 			g_printerr ("ThDevicePool: hal_shutdown() problem!\n");
@@ -285,6 +308,7 @@ device_pool_finalize (GObject *object)
 			g_printerr ("ThDevicePool: libhal_ctx_shutdown() problem!\n");
 		libhal_ctx_free (pool->priv->hal_ctx);
 #endif
+#endif
 	}
 	
 	for (l = pool->priv->trackers;  l;  l = l->next)
@@ -385,8 +409,12 @@ dp_reconnect_to_hal_cb (ThDevicePool *pool)
 	if (!libhal_ctx_init (new_hal_ctx, NULL))
 		g_warning ("libhal_ctx_init() failed at %s!\n", G_STRLOC);
 #else
+#ifdef NOHAL
+	new_hal_ctx = NULL;
+#else
 	new_hal_ctx = hal_initialize (&disc_drive_hal_cb_funcs, TRUE);
 #endif
+#endif
 
 	if (new_hal_ctx) 
 	{
@@ -417,9 +445,14 @@ dp_do_filter_dbus_msg (DBusConnection *connection, DBusMessage *message, void *d
 {
 	LibHalContext *ctx = (LibHalContext*) data;
 
+#ifdef  NOHAL
+	assert(0);
+	if (0)
+#else
 	if (dbus_message_is_signal (message,
 	                            DBUS_INTERFACE_ORG_FREEDESKTOP_LOCAL,
 	                            "Disconnected"))
+#endif
 	{
 		ThDevicePool  *pool;
 		
@@ -642,9 +675,13 @@ device_pool_device_is_volume (ThDevicePool *pool, const gchar *udi)
 {
 	LibHalContext *ctx = pool->priv->hal_ctx;
 
+#ifdef  NOHAL
+	assert(0);
+#else
 	if (!hal_device_property_exists (ctx, udi, "info.capabilities")
 	 || !hal_device_query_capability (ctx, udi, "volume"))
 		return FALSE;
+#endif
 	
 	return TRUE;
 }
@@ -660,7 +697,10 @@ device_pool_send_initial_state (ThDevicePool *pool, ThDeviceTracker *tracker)
 {
 	char **devs;
 	int    i, num_devs;
-	
+
+#ifdef  NOHAL
+	return;
+#else	
 	if (!hal_device_exists (pool->priv->hal_ctx, "/org/freedesktop/Hal/devices/computer"))
 	{
 		/* libhal will automatically notice when hald is 
@@ -691,6 +731,7 @@ device_pool_send_initial_state (ThDevicePool *pool, ThDeviceTracker *tracker)
 	}
 	
 	hal_free_string_array (devs);
+#endif
 }
 
 /***************************************************************************
diff --git a/src/th-device-tracker.h b/src/th-device-tracker.h
index cfaba32..30ab7a8 100644
--- a/src/th-device-tracker.h
+++ b/src/th-device-tracker.h
@@ -18,7 +18,11 @@
 #ifndef _th_device_tracker_h_included_
 #define _th_device_tracker_h_included_
 
+#define NOHAL
+
+#ifndef NOHAL
 #include <libhal.h>
+#endif
 #include <glib-object.h>
 
 #include <dbus/dbus-glib-lowlevel.h>
@@ -66,6 +70,11 @@
 typedef struct _ThDeviceTracker      ThDeviceTracker;       /* dummy typedef */
 typedef struct _ThDeviceTrackerIface ThDeviceTrackerIface;
 
+#ifdef NOHAL
+struct xx_LibHalContext;
+typedef struct xx_LibHalContexT* LibHalContext;
+#endif
+
 struct _ThDeviceTrackerIface
 {
 	GTypeInterface  g_iface;
diff --git a/src/th-disc-drive-pool.c b/src/th-disc-drive-pool.c
index 2e35d08..fc99397 100644
--- a/src/th-disc-drive-pool.c
+++ b/src/th-disc-drive-pool.c
@@ -35,6 +35,11 @@
 
 #include <glib/gi18n.h>
 
+#ifdef NOHAL
+#include <assert.h>
+#endif
+
+
 /* number of seconds after which we try to find DVD drives
  *  using other mechanisms than HAL, if we haven't found
  *  any drives until then that is. */
@@ -442,9 +447,11 @@ disc_drive_pool_add_disc_to_drive (ThDiscDrivePool *ddpool,
 		return;
 	
 	g_datalist_set_data (&ddpool->priv->drives, disc_udi, drive);
-	
+
+#ifndef  NOHAL
 	if (hal_device_property_exists (ddpool->priv->hal_ctx, disc_udi, "volume.label"))
 		label = hal_device_get_property_string (ddpool->priv->hal_ctx, disc_udi, "volume.label");
+#endif
 	
 	if (label == NULL)
 		label = strdup ("(no title)");
@@ -552,7 +559,9 @@ disc_drive_pool_get_drive_info (ThDiscDrivePool *disc_pool,
 	gchar         *product = NULL;
 
 	ctx = disc_pool->priv->hal_ctx;
-
+#ifdef NOHAL
+	assert(0);
+#else
 	device = hal_device_get_property_string (ctx, udi, "block.device");
 	g_return_val_if_fail (device != NULL, FALSE);
 
@@ -593,7 +602,7 @@ disc_drive_pool_get_drive_info (ThDiscDrivePool *disc_pool,
 	hal_free_string (device);
 	hal_free_string (vendor);
 	hal_free_string (product);
-	
+#endif	
 	return TRUE;
 }
 
@@ -750,9 +759,13 @@ disc_pool_device_is_dvd_drive (ThDiscDrivePool *disc_pool, const gchar *udi)
 {
 	LibHalContext *ctx = disc_pool->priv->hal_ctx;
 
+#ifdef  NOHAL
+	//assert(0);
+#else
 	if (!hal_device_property_exists (ctx, udi, "storage.cdrom.dvd")
 	 || !hal_device_get_property_bool (ctx, udi, "storage.cdrom.dvd"))
 		return FALSE;
+#endif
 
 	return TRUE;
 }
@@ -874,7 +887,9 @@ disc_pool_device_prop_mod (ThDeviceTracker *tracker,
 
 	disc_pool = TH_DISC_DRIVE_POOL (tracker);
 	ctx = disc_pool->priv->hal_ctx;
-
+#ifdef NOHAL
+	assert(0);
+#else
 	/* could be because drive is removed, or driver is unloaded etc. */
 	if (is_removed 
 	 || !hal_device_property_exists (ctx, udi, "storage.cdrom.dvd")
@@ -889,6 +904,7 @@ disc_pool_device_prop_mod (ThDeviceTracker *tracker,
 		if (!disc_drive_pool_get_drive_from_udi (disc_pool, udi))
 			disc_drive_pool_add_drive (disc_pool, udi);
 	}
+#endif
 }
 
 /***************************************************************************

Re: [Thoggen-devel] thoggen

[Tim-Philipp M. <t....@ze...>]

On Tue, 2013-10-29 at 21:55 -0700, Martin Uecker wrote:

Hi Martin,

> I used to use thoggen once in a while and was a bit disappointed
> to learn that it does not work anymore on modern distributions
> because apparently stable interfaces and backwards compatibility 
> are not cool anymore.

To be fair, sometimes you just have to replace old stuff that's not up
to scratch. Don't think anyone will miss HAL..

> Anyway, I simply ripped out the HAL stuff which makes thoggen
> compile and work again - at least for me. The patch is attached.
> Not sure what functionality has been lost though.

Did you forget to attach the patch by any chance?

Functionality lost might be that you have to restart Thoggen to make it
pick up an external DVD drive that you plug in. Not sure if it will
detect you inserting a disc after you started it either.

I plan to port Thoggen over to 1.0 once this lands in GStreamer for dvd
drives: https://bugzilla.gnome.org/show_bug.cgi?id=678402 (any day now).

> Or can someone recommend an alternative to thoggen which just
> works?

Handbrake perhaps? I hear Christian also added DVD ripping features to
Transmageddon recently, but not sure if it landed in a release yet.

Cheers
 -Tim

[Thoggen-devel] thoggen

[Martin U. <ue...@ee...>]

Hi,

I used to use thoggen once in a while and was a bit disappointed
to learn that it does not work anymore on modern distributions
because apparently stable interfaces and backwards compatibility 
are not cool anymore.

Anyway, I simply ripped out the HAL stuff which makes thoggen
compile and work again - at least for me. The patch is attached.
Not sure what functionality has been lost though.

Or can someone recommend an alternative to thoggen which just
works?


Martin

[Thoggen-devel] Thoggen Documentation

[Jarlath R. <jar...@gm...>]

I'm going to have some time coming up and I'm happy to put together 
comprehensive user documentation for Thoggen, which shouldn't take too 
long.

I see there is a place-holder for this on the web site. Is there a need 
for documentation?

Jarlath

PS: http://thoggen.net/mailing-lists/ also needs updating as 
registration is in fact required to post to the list now.

Re: [Thoggen-devel] using libxine for decoding

[Matt Z. <mzagrabe@d.umn.edu>]

On Sat, Sep 25, 2010 at 6:47 AM, Tim-Philipp Müller <t....@ze...> wrote:
> On Tue, 2010-08-17 at 09:28 -0500, Matt Zagrabelny wrote:
>
> Hi,
>
>> Recently I've been having more (and more) issues with thoggen using
>> libdvdread to decode the dvds I'm attempting to rip and encode.
>> However, they all play flawlessly with xine. Does anyone have any idea
>> how difficult it would be to graft in decoding support using libxine?
>
> Apologies for the late reply. Was away on holiday and travelling.
>
> So what kind of issues are you having exactly?

A few different types. I am not sure the best way to explain them all,
but with the Disney Movie, "UP", it thoggen gives the following error:

*** libdvdread: CHECK_VALUE failed in
/build/buildd-libdvdread_4.1.3-10-amd64-..../ifo_read.c:1202***
***for vts_ptt_srpt->title[i].ptt[j].pgn != 0***

And locks up while "Retrieving DVD title details..."

Also, the system is pretty much unresponsive at this point, I'll have
to reboot to get it back. (The disk, processor (user/system) are all
nearly maxed out.)


> Presumably when you watch those DVDs using xine you are using the DVD
> navigation menus, right?

Yes.

 Does it work in GStreamer/Totem with the
> navigation menus as well?

Not as well (or not at all). The video is much skippier.

I've done things like:

ddrescue
dvdbackup
thoggen

With that method I can rip, but it is a terrible rip. The languages
seem to be all messed up and there are "loops" in the video.

> Those are two different approaches really, it's not so straight-forward
> to rip from the navigation menu.

Sure. I've had remarkably better luck with xine than with libdvdread
programs for viewing DVDs, so I thought I would ask. I've pestered the
xine folks too about consolidating their work with the libdvdread
people, I don't think anyone cares too much, though.

-matt zagrabelny

PS. Thanks for thoggen, it is nice to have a front end for a theora
encoder (for use anti patent individuals.)

Re: [Thoggen-devel] using libxine for decoding

[Tim-Philipp M. <t....@ze...>]

On Tue, 2010-08-17 at 09:28 -0500, Matt Zagrabelny wrote:

Hi,

> Recently I've been having more (and more) issues with thoggen using
> libdvdread to decode the dvds I'm attempting to rip and encode.
> However, they all play flawlessly with xine. Does anyone have any idea
> how difficult it would be to graft in decoding support using libxine?

Apologies for the late reply. Was away on holiday and travelling.

So what kind of issues are you having exactly?

Presumably when you watch those DVDs using xine you are using the DVD
navigation menus, right? Does it work in GStreamer/Totem with the
navigation menus as well?

Those are two different approaches really, it's not so straight-forward
to rip from the navigation menu.

 Cheers
  -Tim

Marcelo Martínez invited you to Dropbox

[Dropbox <no-...@dr...>]

Marcelo Martínez wants you to use Dropbox to sync and share files online and across computers.

Get started here: http://www.dropbox.com/link/20.yOl1jYnJ57/NjMwNjk3NTkwNw

- The Dropbox Team

____________________________________________________ 
To stop receiving invites from Dropbox, please go to http://www.dropbox.com/bl/a9d385417e5b/thoggen-devel%40lists.sourceforge.net

Re: [Thoggen-devel] using libxine for decoding

[Onkar S. <onk...@gm...>]

On Tue, Aug 17, 2010 at 7:58 PM, Matt Zagrabelny <mzagrabe@d.umn.edu> wrote:
> Hello,
>
> Recently I've been having more (and more) issues with thoggen using
> libdvdread to decode the dvds I'm attempting to rip and encode.
> However, they all play flawlessly with xine. Does anyone have any idea
> how difficult it would be to graft in decoding support using libxine?

Thoggen uses gstreamer framework for encoding/decoding. Gstreamer in
turn uses libdvdread. Considering that gstreamer does not have much in
common with libxine I don't think it is possible to use libxine for
decoding.

By the way, AFAIK libxine uses an internal copy of libdvdread.
libdvdread maintenance is done by mplayer team now. So if there is
something which works with libxine's internal libdvdread but not with
upstream libdvdread you need to complain to mplayer team.


Onkar
-- 
Passion - Some people climb mountains - others write Free software.
Don't ask why - the reason is the same.

[Thoggen-devel] using libxine for decoding

[Matt Z. <mzagrabe@d.umn.edu>]

Hello,

Recently I've been having more (and more) issues with thoggen using
libdvdread to decode the dvds I'm attempting to rip and encode.
However, they all play flawlessly with xine. Does anyone have any idea
how difficult it would be to graft in decoding support using libxine?

Thanks for the info.

-matt zagrabelny

Re: [Thoggen-devel] Subtitle encoding using kate codec

[Onkar S. <onk...@gm...>]

On Tue, May 25, 2010 at 11:21 PM, Tim-Philipp Müller <t....@ze...> wrote:
> On Tue, 2010-05-11 at 20:17 +0530, Onkar Shinde wrote:
>
>> > Yes, I've got the patches locally. Now that the GStreamer kate elements
>> > are up to scratch, the only thing that's missing is me finding some time
>> > to finish them up and test them a bit. So real soon now (tm).
>>
>> Any update on this?
>
> Sorry, slipped down on my TODO list a bit. Haven't gotten around to it
> yet, but still intend to do so. Thanks for the reminder.
>

Gentle reminder once again. :-)


Onkar
-- 
Passion - Some people climb mountains - others write Free software.
Don't ask why - the reason is the same.

Re: [Thoggen-devel] Subtitle encoding using kate codec

[Tim-Philipp M. <t....@ze...>]

On Tue, 2010-05-11 at 20:17 +0530, Onkar Shinde wrote:

> > Yes, I've got the patches locally. Now that the GStreamer kate elements
> > are up to scratch, the only thing that's missing is me finding some time
> > to finish them up and test them a bit. So real soon now (tm).
> 
> Any update on this?

Sorry, slipped down on my TODO list a bit. Haven't gotten around to it
yet, but still intend to do so. Thanks for the reminder.

Cheers
 -Tim

Re: [Thoggen-devel] Subtitle encoding using kate codec

[Tim-Philipp M. <t....@ze...>]

On Tue, 2010-05-11 at 20:17 +0530, Onkar Shinde wrote:

> > Yes, I've got the patches locally. Now that the GStreamer kate elements
> > are up to scratch, the only thing that's missing is me finding some time
> > to finish them up and test them a bit. So real soon now (tm).
> 
> Any update on this?

Sorry, slipped down on my TODO list a bit. Haven't gotten around to it
yet, but still intend to do so. Thanks for the reminder.

Cheers
 -Tim

Re: [Thoggen-devel] Subtitle encoding using kate codec

[Onkar S. <onk...@gm...>]

On Thu, Mar 18, 2010 at 6:12 PM, Tim-Philipp Müller <t....@ze...> wrote:
> On Mon, 2010-03-08 at 17:20 +0530, Onkar Shinde wrote:
>
> Hi,
>
>> While reading some info about kate [1] codec I found out that kate git
>> repository has a patch for thoggen to make use of kateenc element from
>> recent gstreamer version. [2]
>>
>> Is there any chance this could be integrated in thoggen?
>
> Yes, I've got the patches locally. Now that the GStreamer kate elements
> are up to scratch, the only thing that's missing is me finding some time
> to finish them up and test them a bit. So real soon now (tm).

Any update on this?


Regards,
Onkar

Re: [Thoggen-devel] Subtitle encoding using kate codec

[Tim-Philipp M. <t....@ze...>]

On Mon, 2010-03-08 at 17:20 +0530, Onkar Shinde wrote:

Hi,

> While reading some info about kate [1] codec I found out that kate git
> repository has a patch for thoggen to make use of kateenc element from
> recent gstreamer version. [2]
> 
> Is there any chance this could be integrated in thoggen?

Yes, I've got the patches locally. Now that the GStreamer kate elements
are up to scratch, the only thing that's missing is me finding some time
to finish them up and test them a bit. So real soon now (tm).

Cheers 
 -Tim

Re: [Thoggen-devel] discident-glib support

[Tim-Philipp M. <t....@ze...>]

On Thu, 2010-03-18 at 12:45 +0100, David Nielsen wrote:

> Bastian Nocera has just pushed a bit of code that might enhance Thoggen
> considerably.
> 
> http://www.hadess.net/2010/03/guessing-dvd-titles.html

Yes, saw it, seems to work quite well when it works, but the database is
not *that* impressive (quick tests reveals it only has data for 1/3 of
the titles I tested, and those were pretty mainstream titles). It's
quite neat though, so will make sure to add it.

 Cheers
  -Tim

[Thoggen-devel] discident-glib support

[David N. <gno...@gm...>]

Bastian Nocera has just pushed a bit of code that might enhance Thoggen
considerably.

http://www.hadess.net/2010/03/guessing-dvd-titles.html

- David

[Thoggen-devel] Subtitle encoding using kate codec

[Onkar S. <onk...@gm...>]

Hi,

While reading some info about kate [1] codec I found out that kate git
repository has a patch for thoggen to make use of kateenc element from
recent gstreamer version. [2]

Is there any chance this could be integrated in thoggen?

[1] http://wiki.xiph.org/Kate
[2] http://git.xiph.org/?p=users/oggk/kate.git;a=blob;f=diffs/thoggen-with-kate.diff;h=6a221e2d1020751403be8f464b396557095f3352;hb=28e7ee8b668f4442ed0ee45dd577d03c90bf4aee


Onkar
-- 
Passion - Some people climb mountains - others write Free software.
Don't ask why - the reason is the same.

Re: [Thoggen-devel] HAL to DeviceKit recoding

[Onkar S. <onk...@gm...>]

Bram,

I am no thoggen developer and haven't done the kind of programming
related to device access. But as far as I know applications should use
libudev or libgudev APIs for such kind of functionality.


Onkar

Re: [Thoggen-devel] HAL to DeviceKit recoding

[bram <bn...@gm...>]

I've tried looking into it, but it seems to be more confusing then I
thought. I was expecting to find "from HAL to DeviceKit" recoding
tutorials, but instead I'm finding that DeviceKit has been renamed to
udisks and upower[1]. There are not udisks or upower packaged in the
newest Ubuntu yet and (the rename was announced Wed, 02 Dec 2009) it may
take some more months.

I have no real dbus experience, how problematic is this rename? Is it
worth rewriting for DeviceKit and then replacing the dbus root path once
they change to udisks and upower, or should we wait for a bit more?

It seems that there are two files that need attention:
th-device-pool.c:#include <libhal.h>
th-device-tracker.h:#include <libhal.h>

Any idea how intensive a rewrite would be? I could not get any idea from
the internet :(

Bram

[1]
http://www.mail-archive.com/dev...@li.../msg00515.html

On Fri, 2010-01-08 at 08:55 +0000, Tim-Philipp Müller wrote:
> On Fri, 2010-01-08 at 00:47 +0100, bram wrote:
> 
> Hi,
> 
> > I'm currently running Ubuntu Lucid and they are moving away from HAL and
> > towards DeviceKit (udisks and upower??).
> > 
> > Is there currently an effort underway to do the recode, what is the
> > status and what are the opinions on a recode like that?
> 
> Patches welcome :)
> 
> I haven't looked at the newer alternatives yet. (I did play around with
> GLib's new volume monitor for a bit, but unfortunately it doesn't really
> give us enough information, like if the disc in the drive is a CD or DVD
> or somesuch, and it doesn't look like the Gio folks are keen on adding
> things like this either.)
> 
> Cheers
>  -Tim
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> _______________________________________________
> Thoggen-devel mailing list
> Tho...@li...
> https://lists.sourceforge.net/lists/listinfo/thoggen-devel

Re: [Thoggen-devel] HAL to DeviceKit recoding

[Tim-Philipp M. <t....@ze...>]

On Fri, 2010-01-08 at 00:47 +0100, bram wrote:

Hi,

> I'm currently running Ubuntu Lucid and they are moving away from HAL and
> towards DeviceKit (udisks and upower??).
> 
> Is there currently an effort underway to do the recode, what is the
> status and what are the opinions on a recode like that?

Patches welcome :)

I haven't looked at the newer alternatives yet. (I did play around with
GLib's new volume monitor for a bit, but unfortunately it doesn't really
give us enough information, like if the disc in the drive is a CD or DVD
or somesuch, and it doesn't look like the Gio folks are keen on adding
things like this either.)

Cheers
 -Tim

[Thoggen-devel] HAL to DeviceKit recoding

[bram <bn...@gm...>]

Hi thoggen developers,

I'm currently running Ubuntu Lucid and they are moving away from HAL and
towards DeviceKit (udisks and upower??).

Is there currently an effort underway to do the recode, what is the
status and what are the opinions on a recode like that?

Greets,
  Bram

Re: [Thoggen-devel] no region code, but xine plays fine

[Onkar S. <onk...@gm...>]

On Wed, Oct 14, 2009 at 9:33 PM, Matt Zagrabelny <mzagrabe@d.umn.edu> wrote:
> On Wed, 2009-10-14 at 16:45 +0100, Tim-Philipp Müller wrote:
>> On Thu, 2009-10-08 at 21:59 +0100, ogg...@go... wrote:
>>
>> > > I did install regionset and set the region to '1'.
>> >
>> > I'd recommend against that. The region thing is a scam the movie industry
>> > strongarmed hardware manufacturers into adding to prevent players from
>> > playing all DVDs. You'll have to change the region to match whatever DVD
>> > you want to watch, and after a set number of changes, the DVD player may
>> > stop accepting changes, and will only be able to read DVDs marked with
>> > whatever region number it was given last (for some software anyway).
>>
>> With modern DVD drives (RPC-2) the region code may actually be enforced
>> by the firmware on the DVD drive (unless you've flashed firmware that
>> doesn't do that, of course). As far as I know there are drives that
>> simply won't work if you don't set a region code, others may work or not
>> work depending on the DVD or the constellation of the stars. The drive
>> in my old macbook returned garbage data until I set the region code.
>>
>> Having said that: if something works with xine/mplayer or vlc there is
>> no reason why it shouldn't work with GStreamer/Thoggen as well
>> (everything else equal).
>
> No kidding about the constellations. With the same drive I have
> experienced the following for the same disc:
>
> - No recognition of the titles
> - Recognition of the titles, but video is all garbled when encoding
> - Recognition of the titles and encoding is done correctly
>
> It seems like a combination of reboots will yield different results.
>
> Thanks DVD overlords. ;)
>
> Xine still seems to be a bit more stable and consistent than thoggen
> (gstreamer?), WRT getting the titles and extracting video, FWIW.
>
>> > > libdvdread: Can't seek to block 2508160
>> > > libdvdread: DVDDiscId read returned 0 bytes, wanted 32768
>> > >  :: DVDDiscID (/dev/hdd) failed.
>> >
>> > This looks like either a bug in libdvdread, or some other exploit from the
>> > movie industry, which crafts their DVDs to (AFAIK) not quite obey the
>> > filesystem specification, confusing software readers, but not hardware
>> > ones.
>> >
>> > Maybe you could make sure, as a first step, that you have the latest version
>> > of libdvdread ? I think (but am not certain) that xine has a custom version
>> > of some DVD reading library, maybe this very one. You might want to see if
>> > this has patches that are not in the version GStreamer uses.
>>
>> My first guess would also be a bug in the version of libdvdread that
>> GStreamer/Thoggen are using. What distro/version are you on?
>
> Debian, sid/unstable.
>
>>  What
>> version of libdvdread is installed?
>
> % dpkg -l libdvdread4
> ii  libdvdread4      4.1.3-7          library for reading DVDs

Mplayer devs forked libdvdread for doing lots of bug fixes. The
version you are seeing is the forked one. AFAIK, xine uses an old
private copy of libdvdread. Also mplayer uses a private copy (may not
be old) of of libdvdread. Not sure why mplayer doesn't use the public
libdvdread that they forked. :-)


Onkar

Re: [Thoggen-devel] no region code, but xine plays fine

[Matt Z. <mzagrabe@d.umn.edu>]

On Wed, 2009-10-14 at 16:45 +0100, Tim-Philipp Müller wrote:
> On Thu, 2009-10-08 at 21:59 +0100, ogg...@go... wrote:
> 
> > > I did install regionset and set the region to '1'.
> > 
> > I'd recommend against that. The region thing is a scam the movie industry
> > strongarmed hardware manufacturers into adding to prevent players from
> > playing all DVDs. You'll have to change the region to match whatever DVD
> > you want to watch, and after a set number of changes, the DVD player may
> > stop accepting changes, and will only be able to read DVDs marked with
> > whatever region number it was given last (for some software anyway).
> 
> With modern DVD drives (RPC-2) the region code may actually be enforced
> by the firmware on the DVD drive (unless you've flashed firmware that
> doesn't do that, of course). As far as I know there are drives that
> simply won't work if you don't set a region code, others may work or not
> work depending on the DVD or the constellation of the stars. The drive
> in my old macbook returned garbage data until I set the region code.
> 
> Having said that: if something works with xine/mplayer or vlc there is
> no reason why it shouldn't work with GStreamer/Thoggen as well
> (everything else equal).

No kidding about the constellations. With the same drive I have
experienced the following for the same disc:

- No recognition of the titles
- Recognition of the titles, but video is all garbled when encoding
- Recognition of the titles and encoding is done correctly

It seems like a combination of reboots will yield different results.

Thanks DVD overlords. ;)

Xine still seems to be a bit more stable and consistent than thoggen
(gstreamer?), WRT getting the titles and extracting video, FWIW.

> > > libdvdread: Can't seek to block 2508160
> > > libdvdread: DVDDiscId read returned 0 bytes, wanted 32768
> > >  :: DVDDiscID (/dev/hdd) failed.
> > 
> > This looks like either a bug in libdvdread, or some other exploit from the
> > movie industry, which crafts their DVDs to (AFAIK) not quite obey the
> > filesystem specification, confusing software readers, but not hardware
> > ones.
> >
> > Maybe you could make sure, as a first step, that you have the latest version
> > of libdvdread ? I think (but am not certain) that xine has a custom version
> > of some DVD reading library, maybe this very one. You might want to see if
> > this has patches that are not in the version GStreamer uses.
> 
> My first guess would also be a bug in the version of libdvdread that
> GStreamer/Thoggen are using. What distro/version are you on?

Debian, sid/unstable.

>  What
> version of libdvdread is installed?

% dpkg -l libdvdread4
ii  libdvdread4      4.1.3-7          library for reading DVDs

Cheers,

-- 
Matt Zagrabelny - mzagrabe@d.umn.edu - (218) 726 8844
University of Minnesota Duluth
Information Technology Systems & Services
PGP key 1024D/84E22DA2 2005-11-07
Fingerprint: 78F9 18B3 EF58 56F5 FC85  C5CA 53E7 887F 84E2 2DA2

He is not a fool who gives up what he cannot keep to gain what he cannot
lose.
-Jim Elliot

Re: [Thoggen-devel] no region code, but xine plays fine

[Tim-Philipp M. <t....@ze...>]

On Thu, 2009-10-08 at 21:59 +0100, ogg...@go... wrote:

> > I did install regionset and set the region to '1'.
> 
> I'd recommend against that. The region thing is a scam the movie industry
> strongarmed hardware manufacturers into adding to prevent players from
> playing all DVDs. You'll have to change the region to match whatever DVD
> you want to watch, and after a set number of changes, the DVD player may
> stop accepting changes, and will only be able to read DVDs marked with
> whatever region number it was given last (for some software anyway).

With modern DVD drives (RPC-2) the region code may actually be enforced
by the firmware on the DVD drive (unless you've flashed firmware that
doesn't do that, of course). As far as I know there are drives that
simply won't work if you don't set a region code, others may work or not
work depending on the DVD or the constellation of the stars. The drive
in my old macbook returned garbage data until I set the region code.

Having said that: if something works with xine/mplayer or vlc there is
no reason why it shouldn't work with GStreamer/Thoggen as well
(everything else equal).


> > libdvdread: Can't seek to block 2508160
> > libdvdread: DVDDiscId read returned 0 bytes, wanted 32768
> >  :: DVDDiscID (/dev/hdd) failed.
> 
> This looks like either a bug in libdvdread, or some other exploit from the
> movie industry, which crafts their DVDs to (AFAIK) not quite obey the
> filesystem specification, confusing software readers, but not hardware
> ones.
>
> Maybe you could make sure, as a first step, that you have the latest version
> of libdvdread ? I think (but am not certain) that xine has a custom version
> of some DVD reading library, maybe this very one. You might want to see if
> this has patches that are not in the version GStreamer uses.

My first guess would also be a bug in the version of libdvdread that
GStreamer/Thoggen are using. What distro/version are you on? What
version of libdvdread is installed?

Cheers
 -Tim

Re: [Thoggen-devel] no region code, but xine plays fine

[Matt Z. <mzagrabe@d.umn.edu>]

On Thu, 2009-10-08 at 21:59 +0100, ogg...@go... wrote:
> > I did install regionset and set the region to '1'.
> 
> I'd recommend against that.

Errrr... too late. :/

>  The region thing is a scam the movie industry
> strongarmed hardware manufacturers into adding to prevent players from
> playing all DVDs. You'll have to change the region to match whatever DVD
> you want to watch, and after a set number of changes, the DVD player may
> stop accepting changes, and will only be able to read DVDs marked with
> whatever region number it was given last (for some software anyway).
> 
> > libdvdread: Can't seek to block 2508160
> > libdvdread: DVDDiscId read returned 0 bytes, wanted 32768
> >  :: DVDDiscID (/dev/hdd) failed.
> 
> This looks like either a bug in libdvdread, or some other exploit from the
> movie industry, which crafts their DVDs to (AFAIK) not quite obey the
> filesystem specification, confusing software readers, but not hardware
> ones.
> 
> Maybe you could make sure, as a first step, that you have the latest version
> of libdvdread ?

Looks latest - 4.1.3.

>  I think (but am not certain) that xine has a custom version
> of some DVD reading library, maybe this very one. You might want to see if
> this has patches that are not in the version GStreamer uses.

Sure, will check.


-- 
Matt Zagrabelny - mzagrabe@d.umn.edu - (218) 726 8844
University of Minnesota Duluth
Information Technology Systems & Services
PGP key 1024D/84E22DA2 2005-11-07
Fingerprint: 78F9 18B3 EF58 56F5 FC85  C5CA 53E7 887F 84E2 2DA2

He is not a fool who gives up what he cannot keep to gain what he cannot
lose.
-Jim Elliot