Oggs, AVI’s affected as well. Apparently it’s just MKV’s that either don’t exhibit this or just manifest it differently.

Actually, with the MP3 it’s Bug #918077 (which I just reported). Could be the same underlying issue, but I felt it best to report these separately as the symptom differs slightly.

See Bug #907644 for a similar issue with MKV files.

With MP4 and MP3 files, with just one such file on the playlist and looped (with repeat mode on), the file is played through twice with no problem, then it just stops at the end. Restarting the video by double-clicking on the playlist item works.

As in #907644, if you add another file (or another instance of the same file) to the playlist and let it loop between the two, there’s no problem. But with the single file repeating the bug is 100% reproducible. Not reproducible with VLC.

Steps to reproduce:
1. Load an MP3 or MP4 in Totem.
2. Set ’Repeat Mode’ on.
3. Let the file play through two rounds.

What happens:
At the end of second play, the playing stops and does not start again by itself.

What I expect to happen:
For the file to repeat ad infinitum.

No problem, thank you for your rapid response to this and for the learning I gained! I’ve modified the scripts accordingly and it all works smoothly (and as intended) now.

I can’t tell if you can see it from the Apport-attached files, so I’ll add that I’m running Unity 2D here.

I’ve had sporadic freezes on this system before since upgrading to Precise, but I haven’t had the resources to try and ssh in prior to this, so I can’t tell if this has occurred before. Now that I have an additional laptop I can hopefully catch this again if it occurs.

I screwed up with the logs first, but then managed to salvage dmesg with a Trace from terminal buffer. I’ll attach it separately below.

I wasn’t active on the desktop when the freeze happened (had my hands on the laptop). At least Chromium, Transmission and Google Music were running at the time.

(I’m not familiar with Traces so I’ll just pick something from the first line as title. Feel free to change it if needed.)

Mathieu, here’s a backtrace hopefully with what you requested for (with network-manager-gnome-dbgsym installed).

You’re right: it’s announce-ip and another local script from /etc/network/if-up.d/ (I’m attaching it here) that both seem to trigger this if either is present. This other one’s sort of like the opposite of my announce-ip, there to update /etc/hosts with data from hosts elsewhere on the net my server knows about (that announce themselves with announce-ip). This combination used to work back with ifupdown alpha but now with beta causes the wait.

To clarify: with both scripts removed from if-up.d the 60+ second wait doesn’t appear during boot, but with either script in place the wait is there.

To be sure, I installed the latest ifupdown that’s just appeared in the repos (0.7~beta2ubuntu2) also, and there’s no change compared to 0.7~beta2ubuntu1 (wait is there when the scripts are there).

The question now becomes whether I’ve initially designed the scripts wrong with regards to how things in if-up.d should work, and it just happened to work with the alpha, or did something in ifupdown’s handling of if-up.d change between alpha and beta so that things that should work no longer do.

With my knowledge of things I’d bet on the former, but you can probably enlighten me on this. My assumption’s been that the scripts in if-up.d are run after network interfaces have been brought up.

Sure. This script sources another local file for configuration, but that one’s just a one-line variable declaration for the $URL. (I’m omitting that one because it has my password for the script’s server side.)

So, the body looks precisely the same. Can’t really say I’d wondered about that though, unlike with the face.