sound_repeat option not working

Unfortunately I don't have a 12.04 system readily available. Therefore a debug log would be very helpful. It puzzles me that there is no output at all when you start alarm-clock-applet from shell. There should be plenty of debug information.

Can you please paste the output of the following five commands?

file $(which alarm-clock-applet)

sha1sum $(which alarm-clock-applet)

killall alarm-clock-applet

alarm-clock-applet --help

alarm-clock-applet

On 13/04/2012 01:26, Johannes H. Jensen wrote:
> Unfortunately I don't have a 12.04 system readily available. Therefore a
> debug log would be very helpful. It puzzles me that there is no output
> at all when you start alarm-clock-applet from shell. There should be
> plenty of debug information.

Yeah, I was pretty surprised as well. What are you using to log? Perhaps
something in Glib changed?

> Can you please paste the output of the following five commands?
>
> file $(which alarm-clock-applet)

/usr/bin/alarm-clock-applet: ELF 64-bit LSB executable, x86-64, version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24,
BuildID[sha1]=0x268b9375cc10fa0ca672ad0fff4c5d1899fc68b5, stripped

> sha1sum $(which alarm-clock-applet)

db8f291ff34ebfaa89341f7c9ded005895ab9a77

> killall alarm-clock-applet

This doesn't work. I think there's a regression in killall that causes it to not
work with long commands.

> alarm-clock-applet --help

Usage:
  alarm-clock-applet [OPTION…]

Help Options:
  -h, --help Show help options
  --help-all Show all help options
  --help-gtk Show GTK+ Options

Application Options:
  --hidden Start hidden
  --display=DISPLAY X display to use

> alarm-clock-applet

Nothing.

I can confirm that this is definitely the alarm-clock-applet that came from the
package in 12.04. But I can't figure out why there's no output.

--
Kind regards,
Loong Jin

As requested:

> file $(which alarm-clock-applet)
/usr/bin/alarm-clock-applet: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x5a6190713548d0c21e08c25eae57ce9702563a49, stripped

> sha1sum $(which alarm-clock-applet)
1f3d3d33299e406404b46c80a8d784b869cfa5f7 /usr/bin/alarm-clock-applet

This one is weird as I have the applet in the notification area
and I can interact with the applet (create new alarms, edit alarms, etc.)

Besides using tab completion with the killall command yields 'alarm-clock-applet'

--------------------------------------------
> killall alarm-clock-applet
alarm-clock-applet: proceso no encontrado

> LC_ALL=C killall alarm-clock-applet
alarm-clock-applet: no process found
--------------------------------------------

When alarm-clock-applet in the notification area
--------------------------------------------------
> alarm-clock-applet --help
alarm-clock-applet está ejecutándose, saliendo...

> LC_ALL=C alarm-clock-applet --help
alarm-clock-applet is already running, exiting...

> alarm-clock-applet
alarm-clock-applet está ejecutándose, saliendo...

> LC_ALL=C alarm-clock-applet
alarm-clock-applet is already running, exiting...
--------------------------------------------------

When alarm-clock-applet NOT in the notification area

> alarm-clock-applet --help
Usage:
  alarm-clock-applet [OPTION...]

Help Options:
  -h, --help Show help options
  --help-all Show all help options
  --help-gtk Show GTK+ Options

Application Options:
  --hidden Start hidden
  --display=DISPLAY X display to use

> alarm-clock-applet
It opens the window, in terminal there is no output

If there is any other info that you may need, please ask.

Thanks

On Thu, Apr 12, 2012 at 19:47, Chow Loong Jin <email address hidden> wrote:
>
> Yeah, I was pretty surprised as well. What are you using to log? Perhaps
> something in Glib changed?

I'm using g_debug() and friends to log. I'll have a look in the changelogs
for Glib and check for relevant changes...

Can you please try the attached program on your 12.04 system?

Compile and run it as follows:

$ gcc -W -Wall -o g_debug g_debug.c $(pkg-config --cflags --libs glib-2.0)
$ ./g_debug
** (process:12202): DEBUG: Debugging...
$

On 13/04/2012 02:58, Johannes H. Jensen wrote:
> Can you please try the attached program on your 12.04 system?

Based on Glib 2.32's documentation, g_log_default_handler() that only debug
messages for which G_MESSAGES_DEBUG[1] contains G_LOG_DOMAIN[2] are printed out.

In other words, something like this works:
---8<---
#define G_LOG_DOMAIN "foo"
#include <glib.h>
int main ()
{
    g_debug ("foo");
    return 0;
};
--->8---

$ G_MESSAGES_DEBUG=foo ./a.out

[1]
http://developer.gnome.org/glib/stable/glib-Message-Logging.html#g-log-default-handler
[2]
http://developer.gnome.org/glib/stable/glib-Message-Logging.html#G-LOG-DOMAIN:CAPS

--
Kind regards,
Loong Jin

@hyperair Ah that seems to be different from Glib 2.30! There is no mention of G_MESSAGES_DEBUG in the 2.30 docs: http://developer.gnome.org/glib/stable/glib-Message-Logging.html#g-log-default-handler

Can someone on a 12.04 system please try the following:

$ G_MESSAGES_DEBUG=alarm-clock-applet alarm-clock-applet

or, if that doesn't result in debug output:

$ G_MESSAGES_DEBUG=all alarm-clock-applet

Thanks!

Err, that link was wrong. It was supposed to be: http://developer.gnome.org/glib/2.30/glib-Message-Logging.html#g-log-default-handler

On 14/04/2012 06:20, Johannes H. Jensen wrote:
> @hyperair Ah that seems to be different from Glib 2.30! There is no
> mention of G_MESSAGES_DEBUG in the 2.30 docs:
> http://developer.gnome.org/glib/stable/glib-Message-Logging.html#g-log-
> default-handler
>
> Can someone on a 12.04 system please try the following:
>
> $ G_MESSAGES_DEBUG=alarm-clock-applet alarm-clock-applet
>
> or, if that doesn't result in debug output:
>
> $ G_MESSAGES_DEBUG=all alarm-clock-applet
>
> Thanks!
>

Here you go. The former command does not work as G_LOG_DOMAIN was not defined
during the build, but the latter does.

--
Kind regards,
Loong Jin

On Sat, Apr 14, 2012 at 00:54, Chow Loong Jin <email address hidden> wrote:
>
> Here you go. The former command does not work as G_LOG_DOMAIN was not
> defined
> during the build, but the latter does.

Thank you. Is that log output captured while you trigger the sound_repeat
bug?

On 14/04/2012 07:10, Johannes H. Jensen wrote:
> On Sat, Apr 14, 2012 at 00:54, Chow Loong Jin <email address hidden> wrote:
>>
>> Here you go. The former command does not work as G_LOG_DOMAIN was not
>> defined
>> during the build, but the latter does.
>
>
> Thank you. Is that log output captured while you trigger the sound_repeat
> bug?
>

Yep, specifically this snippet:

----
** (alarm-clock-applet:10081): DEBUG: AlarmSettingsDialog: preview_start...
** (alarm-clock-applet:10081): DEBUG: AlarmSettingsDialog: Freeing media player
0x1d40d20
** (alarm-clock-applet:10081): DEBUG: AlarmSettingsDialog: preview_start...
** (alarm-clock-applet:10081): DEBUG: AlarmSettingsDialog: Freeing media player
0x20a50a0
** (alarm-clock-applet:10081): DEBUG: AlarmSettingsDialog: preview_start...
** (alarm-clock-applet:10081): DEBUG: AlarmSettingsDialog: Freeing media player
0x1b31a40
----

In all three cases, the sound played once, while the "Play" button remained
depressed until manually released by the second click.

--
Kind regards,
Loong Jin

Interesting... From the logs it appears you are creating a new alarm (#4)
but there is no mention of the sound-repeat gconf key being set. On my
system, this key is set to true for all new alarms.

Can you try the following:
1. Create a new alarm, name it "Bug 977110"
2. Paste here the output of the command: gconftool-2 -R /apps/alarm-clock

Finally, is the issue reproducible from alarm-clock trunk?

Thanks!

On Sat, Apr 14, 2012 at 02:36, Chow Loong Jin <email address hidden> wrote:

> On 14/04/2012 07:10, Johannes H. Jensen wrote:
> > On Sat, Apr 14, 2012 at 00:54, Chow Loong Jin <email address hidden>
> wrote:
> >>
> >> Here you go. The former command does not work as G_LOG_DOMAIN was not
> >> defined
> >> during the build, but the latter does.
> >
> >
> > Thank you. Is that log output captured while you trigger the sound_repeat
> > bug?
> >
>
> Yep, specifically this snippet:
>
> ----
> ** (alarm-clock-applet:10081): DEBUG: AlarmSettingsDialog: preview_start...
> ** (alarm-clock-applet:10081): DEBUG: AlarmSettingsDialog: Freeing media
> player
> 0x1d40d20
> ** (alarm-clock-applet:10081): DEBUG: AlarmSettingsDialog: preview_start...
> ** (alarm-clock-applet:10081): DEBUG: AlarmSettingsDialog: Freeing media
> player
> 0x20a50a0
> ** (alarm-clock-applet:10081): DEBUG: AlarmSettingsDialog: preview_start...
> ** (alarm-clock-applet:10081): DEBUG: AlarmSettingsDialog: Freeing media
> player
> 0x1b31a40
> ----
>
> In all three cases, the sound played once, while the "Play" button remained
> depressed until manually released by the second click.
>
> --
> Kind regards,
> Loong Jin
>
> --
> You received this bug notification because you are subscribed to Alarm
> Clock.
> https://bugs.launchpad.net/bugs/977110
>
> Title:
> sound_repeat option not working
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/alarm-clock/+bug/977110/+subscriptions
>

On 18/04/2012 02:36, Johannes H. Jensen wrote:
> Interesting... From the logs it appears you are creating a new alarm (#4)
> but there is no mention of the sound-repeat gconf key being set. On my
> system, this key is set to true for all new alarms.
>
> Can you try the following:
> 1. Create a new alarm, name it "Bug 977110"
> 2. Paste here the output of the command: gconftool-2 -R /apps/alarm-clock

 show_label = true
 /apps/alarm-clock/alarm0:
  repeat = []
  message = Bug #977110
  type = clock
  sound_repeat = true
  sound_file = file:///usr/share/sounds/gnome/default/alerts/bark.ogg
  notify_type = sound
  timestamp = 0
  time = 0
  active = false
  command = rhythmbox-client --play
 /apps/alarm-clock/alarm1:
  repeat = [sun,mon,tue,wed,thu,fri,sat]
  message = wake up
  type = clock
  sound_repeat = true
  sound_file = file:///usr/share/sounds/gnome/default/alerts/bark.ogg
  notify_type = command
  timestamp = 1334707200
  time = 28800
  active = true
  command = alarm-banshee

Looks like it is set. Could it be a gstreamer issue? How are you getting the
sound to repeat?

> Finally, is the issue reproducible from alarm-clock trunk?
Yes.

--
Kind regards,
Loong Jin

Hello,

I installed Ubuntu 12.04, and I confirm that the repeat option doesn't work with me either. I read your responses, I don't have that much knowledge (compiling from source) so I can't post any debug, but when I lauch from the terminal I don't get any error messages.

The last message was 13 days ago, I wonder whether there is any solution? I use this application a lot and I would appreciate a fix a lot :)

I've found that rhythmbox can't repeat any of the alerts, such as bark.ogg or drip.ogg. It will try to for a few times then just quit, but act like its still playing them. I haven't tried it with any other sound files as I don't use rhythmbox.

As a work around, I'm using the custom command feature with vlc, which can repeat sounds.

The command is: vlc -R "file" (you can also use cvlc and it won't bring up a window.)

Actually, it seems to be working somewhat for longer sounds, e.g. /usr/share/sounds/ubuntu/stereo/desktop-login.ogg
The first time, the sound is played from start to finish. The second time though, it seems to skip the first part of the sound. This is also reproducible in Totem. Sounds like a bug in gstreamer or some gst plugin...

Some more investigation revealed that the playback delay only occurs with ogg encoded files. Both wav and flac seems to be unaffected.

Workaround for now: convert the sound file to wav (with soundconverter etc) and use it instead.

I came here to say also the same and saw your comment. Yes, the problem is ogg-specific.

I too was quite disappointed when I installed Alarm-Clock-Applet in Linux Mint 13 and found that the alarm alert sound was played only once, especially since Alarm-Clock-Applet had been working perfectly for me in Linux Mint 11. But LM11 uses version 0.3.1, and LM13 uses version 0.3.2.

Having finally stumbled across this bug report, I can confirm that changing "sonar.ogg" from an OGG file to a WAV file (but leaving the name as "sonar.ogg", which strikes me as deceptive) works.

But I hope that you can soon solve the problem and allow us users to cease having to be deceptive. :-) I depend heavily on Alarm-Clock-Applet!

And, by the way, thank you very much, Mr. Jensen, for having created it.

I'm sorry I haven't had time to look further into this. I did post a question about playback delay on gstreamer-devel, but I didn't receive any reply: http://lists.freedesktop.org/archives/gstreamer-devel/2012-May/035900.html

Hopefully I'll get some time this weekend to work on this...

This has been fixed in revision 219 of trunk. Please test!

This bug was fixed in the package alarm-clock-applet - 0.3.3-1

---------------
alarm-clock-applet (0.3.3-1) unstable; urgency=low

  * [05ffad2] New upstream bugfix release:
    - Automatically detect daylight savings time (LP: #290733)
    - Let the WM decide the initial position of the list window (LP: #800635)
    - Check that media player was created successfully (LP: #823585)
    - Don't show notifications when alarms are stopped/snoozed (LP: #908636)
    - Update timestamp when type is changed for active alarms (LP: #885059)
    - Use segment seeks to prevent playback delays when looping (LP: #977110)
    - Enable alarm when closing the Edit alarm dialog (LP: #824337)
  * [c6f6846] Drop upstreamed Set-appindicator-title.patch
  * [6901288] Bump debhelper compat level to 9 for buildflags
  * [224a210] Drop redundant clean rule
  * [600f7b3] Don't override LDFLAGS directly.
    Use DEB_LDFLAGS_MAINT_APPEND instead to append --as-needed stuff, as per the
    dpkg-buildflags manpage.

 -- Chow Loong Jin <email address hidden> Mon, 04 Jun 2012 04:38:46 +0800

  affects ubuntu/precise/alarm-clock-applet
  status confirmed
  subscribe ubuntu-sru

--
Kind regards,
Loong Jin

This bug is missing information detailed in https://wiki.ubuntu.com/StableReleaseUpdates#Procedure for it to comply with Stable Release Updates process. Please add a test case for recreating and the regression potential. Once this information is added to all the bugs addressed by the package in -proposed we will approve the upload. Thanks!

I've rejected this from the precise-proposed queue; changing the debhelper compat level is not a minimal change, and is not appropriate for an SRU.

The rest of the changes look good, however. Feel free to re-upload a package without that change.

Hi, I'm using Version: 0.3.3-1~joh in Ubuntu 12.04 and "Repeat Sound checkbox = unchecked" continues NOT Working.

ps.: my song is a .ogg file.

Hi, John. Can you please elaborate on your comment above? What do you mean by "not working"? Whe the repeat sound checkbox is unchecked, does the sound not play at all? Does it repeat even though it shouldn't?

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release