Confirming: bug still present in Precise, Synaptic 0.75.2ubuntu9. Reproducible using the steps in the initial report.

Crashes ever so often, during playback or skipping in video using mouse pointer on the timeline. Usually becomes nonresponsive and I have to kill it explicitly from the command-line.

I should supplement ”add another MKV file to the playlist and there’s no problem” with that the second file could also be the same file, so that the playlist is comprised of two instances of the same file. This way it works audiowise the way it should even with the file there just once, so it’s an effective, albeit silly workaround.

With just one file on the playlist and looped (with repeat mode on), at about 0:24 during the second play the audio goes mute and doesn’t recover by itself. Restarting the video by double-clicking on the playlist item makes the audio come back.

The funny thing is, if you add another MKV file to the playlist and let it loop between the two files, there’s no problem. But with the single file repeating it looks to be 100% reproducible.

Doesn’t seem to be reproducible using MP4 or AVI files, just MKV. Not reproducible with VLC. I’ve thus far found at least two MKV files [1], [2] that reproduce this 100 %. IIRC, the issue didn’t occur with these same files back in Lucid.

Steps to reproduce:
1. Download one of the aforementioned MKV files.
2. Load it in Totem.
3. Set ’Repeat Mode’ on.
4. Play the file, wait for it to loop.

What happens:
At about 0:24 during the second play the audio goes mute.

What I expect to happen:
The audio to continue playing normally during the second and subsequent loops also.

*[1] http://www.archive.org/download/GhostbustersToolAssistedSpeedrun/ghostbusters-tas-glitchman.mkv
*[2] http://www.archive.org/download/NesAction52theCheetahmenBySwordlessLinkIn0356.06/action52-cheetahmen-tas-swordlesslink.mkv

Jep, nyt toimii, kiva!

Kappas vain, kiitoksia! Jätän merkittyjen versioiden käyttöliittymän toistaiseksi pois päältä, ja kerron mikäli ongelmia ilmenee.

No problem, and thanks for the rapid response to my bug-report-turned-support-request!

Yes and no. :) No, I’ve never used anything but SLB. Yes, it’s apparently always activated links, but it also used to have the ’Activate all image links in item content’ option. Being able to uncheck that option I could use SLB as I have until now: with lightboxing only on links I’ve manually specified as rel=”slb”. The automatic url-snooping thingy just doesn’t work for me, since I use lots of image links pointing to wiki pages of those images.

FWIW, it was easy to fix this for myself: I just cut process_links() so that it immediately returns with unprocessed $content.

So, uh, how do I retroactively extend this reversed behavior to all the links on my blog relying on the previous behavior? I think it’s easier for me to just downgrade and freeze the plugin back to where it works the way I’ve relied on it functioning up until now.

(Not to be critical of your work; it’s your code and you do with it as you will. It just seems my use-case was niche even until recently, and now it’s no longer supported at all.)

It looks like 1.6.1 now automatically adds a rel=”slb” (plus some slb_group) to image links pointing to url’s ending in a known image postfix. While a nice idea in theory, this does not work well with links pointing to non-image content that ends in an image postfix.

Steps to reproduce:
1. Create an image link pointing to a picture page in Wikimedia Commons.
2. Try clicking the link with SLB activated.

What happens:
SLB tries to lightbox the Commons page.

What I expect to happen:
I’d expect SLB not to mess with the link so that when I click the image, I’m taken to the Commons page as usual.

Other notes:
I don’t think there’s any way around this other than disabling the automatic rel=”slb”’ing feature entirely (which the plugin currently, AFAICS, doesn’t allow me to do). There’s no reliable way to determine a link *really* points to an image just by looking at the url.