Thanks, vdemuth. It's useful to know that the problem exists only for some users, not for all. The question is now: How could I track this further down in order to identify what causes the different behaviour.

gargamel

This is what Chrome gives me for the URL to the first video:

This is what Konqueror gives me for the URL to the first video:

I got both by right-clicking on the video and choosing "Copy Video URL."

Interesting. I get the same URL for the first video in Konqueror. Seamonkey, however, gives me WebM instead of MP4:
Now we are getting closer: When I open this URL with Konqueror, an extra window with dialog appears, asking me what program to use in order to play the video. The default is MPlayer, and when I confirm that I want to use it, it immediately downloads and starts playing the video in the extra window.

So, could it be related to some inappropriate file type associations with "helper" applications? I'll try to find out how to reset these associations to "factory" settings and then try again. This will take a few days, as the changed associations are caused by the installation of several 3rd party applications, such as Kaffeine. I'll have to de-install these from my system, first, and then reset the file type associations to default. As this is my main system, and my current workload is above average, I'll probably have to wait for the weekend before doing this.

In the meantime any advice is welcome!

gargamel

Kind of a progress status. ;)

Instead of removing applications from my system I found the directory ~/.local/share/mime, deleted it and then experimented quite a bit with the file associations for MP4 and WebM, both audio and video, and with different browser id strings. However, here I can only choose from a pre-defined selection (drop-down list) of older browsers, and the actual client string doesn't change, it seems. Unfortunately I found no way to extend the list and add, e.g., Firefox 24.x. The most recent Firefox represented in the list is Firefox 3.6.0. :(

Regardless of the browser id I choose, the websites opens the MP4 version. Unfortunately, clicking on on of the videos still only shows the 'wait' circle. So I copied the video URLs into another window of Konqueror.
Result for MP4: No change, no success.
Result for WebM: Konqueror offers me to open the video in KPlayer or MPlayer, and both play the video just fine.

Actually I though WebM was a web standard, and as such all modern browsers should support it out-of-the-box, but Konqueror needs external helper applications for this.

Therefore I'd still appreciate any hints or tips how to proceed to track this down. I'd subimt a bug report to KDE/Konqueror, but as I said the same problem exists for Qt, but non-KDE browser, such as qupzilla (from SBo).

gargamel

OK, this is the solution I have here that plays both mp4 and webm within konqueror.

1) make sure you have the vlcplayer plugin for firefox. On a 64bit system that's /usr/lib64/mozilla/plugins/libvlcplugin.so
2) ensure konqueror can see the plugin in the konqueror settings dialogue plugins
3) set file association in konqueror for webm to be VLCPlayer
4) set konqueror embedding to Netscape Plugin Viewer (nsplugin)

Restart Konqueror and you should be working correctly.

Good luck and Merry Christmas

Thanks, vdemuth, and also a Merry Christmas to all of you!

What you suggest works, if I open the video URL directly in Konqueror. However, VLC is not even required, MPlayer can play WebM streams just as well. But my problem is not that Konqueror wouldn't play WebM, but that the web page generates an obviously broken MP4 link for Konqueror, while the WebM URL for Mozilla browsers works without problems.

So I can open the page in a Mozilla browser, copy the video URL to Konqueror and then click on the video. With my current settings Konqueror asks me to open the video in an external viewer. I select, e.g., MPlayer, and it plays the video just fine. So if the page would open a WebM stream, Konqueror would have methods to play it (embedded or with the support of an external viewer).

Unfortunately, for Konqueror the web page doesn't provide a working URL to a WebM stream, but a broken one to an MP4 stream. If I open the page in Konqueror, copy the URL to Seamonkey and click on the video, I get a "404 not found" error. That explains why the Ajax "wait" circle is turning around until the world stands still...

Preliminary Conclusion

1. As dugan said, the page has bugs. Apart from other things, the URL generated for MP4 video streams is broken. I guess, that other web clients (browsers) also suffer from this. I'll send a bug report to the web master, although I am not a Honda customer or in any way affiliated with the firm.
2. Depending on the client (browser) a different streaming format is provided. For recent Mozilla browsers WebM is used, which works just fine. Therefore I'll try to find a way to change the browser id string to something that makes Konqueror identify itself as a recent Mozilla browser.

For the second step I'd appreciate, if those of you for whom the page is working, would share their browser id settings.
Thanks to all of you!

gargamel

Where I say, "no," means I've left the check box blank:

View mode, Webkit.

Brower ID, Send identificatioin, Default idenification,
Mozilla/5.0 (X11;) AppleWebKit/534.34 (KHTML, like Gecko) konqueror/4.11.4 Safari/534.34
"no" add operating system name,
"no" language information.

Konqueror settings, starting from the top:

Form completion, 10.
Miscellaneous, allow automatic delayed reloading/redirecting.
Enable access key activation.
"no" DNT header
offer to save passwords.

No proxy.

Adblock filters. Enable filters (but none enabled (all boxes left blank).

Enable Web shortcuts (but none enabled).

Use cache. Keep cache in sync.

History. 0 URLS (in other words, no history).

Cookies. Enable cookies,
only accept from originating server,
automatically accept session cookies,
accept until end of session.

Browser ID, see the third sentence above.

Java & javascript. Enable java globally.
use security manager.
shutdown applet server when in active for more than 60 seconds.
Path to java executable, or 'java': java

Plugins.
Enable plugins globally.
"no" only allow http, etc.
"no" load plugins on demand only.
CPU priortry for plugins: highest.

On the tab page, labeled, "Plugins" to the right of the "Global Setting," tab, I've had to scan for plugins each time I've installed Konqueror.

Just a note. It doesn't matter, I guess, if you are using Konqueror in KDE, as it is meant to be used, but when using it in Xfce it consumes a huge amount of resources. Just to run it, Konqueror, the wallet, sweeper and all the support "services" you are looking at 600+ megs of RAM. Of course, in today's world that isn't much anymore, but to an old geezer like myself, that seems outrageous just to run a browser.
Each to their own.

Merry Christmas to You and Yours!

:hattip:

Not reading much here but (latest) Firefox64-for-me plays it fine here in Debian-7.2\Jessie-KDE, best wishes and have fun.

I know, but this thread is about Qt/KDE web browsers, which is NOT anything Mozilla, Google etc.... ;)

gargamel

@cwizardone: Thanks a lot for sharing all your Konqueror settings. I have 'replicated' them for my environment, but unfortunately the problem persists.... :(
It's really hard to tell, what makes it work for you, but not for me, Alien Bob and some others... This is really a nut. Actually I'd open a bug report for the KDE developers, but with the information we have collected so far it will be very hard for them to fix this. It might well be that it works for the responsible developer just as well as it does for you. What should he or she do then?

On the other hand I am really running out of ideas now. Even with the same (or VERY similar) settings it works for one user, but not for another. And the last step showed, that the browser id is not making the difference. But what else could you think of, then?

Best wishes,

gargamel

You have probably already done this, but, if not, have you considered deleting, ~/.kde/share/apps/konqueror and starting over? Or, if you have the time, logging completely out of KDE, deleting ~/.kde and starting over?
Just a thought.
Cheers.
:)

Yes, I thought of both, but did only the first, ie deleting ~/.kde/share/apps/konqueror. Also I deleted /tmp/kde*, but still no success. I really don't get it, how equal or similar setups can produce such different results.

However, I am reluctant to delete ~/.kde as a whole, as I would lose my KMail configuration (and possibly other things I need) if I did. Currently I am using Seamonkey, but that's currently a PoC. Until recently KMail was my preferred mail client. Of course, the root cause might be buried somewhere here. When I have more time, I plan to check what files I need and backup these, before I delete ~/.kde (and /tmp/kde* and ~/.cache, although this for Xfce, I think, etc.), log out and re-log in.

Thanks again!

gargamel

Loved KMail, but the developers refuse to bring it into the 21th Century. In a search for a replacement I tried just about everything else, including Seamonkey Mail, but have settled on Thunderbird as the ultimate compromise.
For many months now I've been looking for a replacement for Opera 12.1x and, again, have tried many browsers, and it appears Firefox is going to be the best compromise. I really like Konqueror, but it uses far too many resources, i.e., more than I think it should to get the job done. Looked at all the others, Midori, QupZilla, Seamonkey, Chromium/Chrome, etc., and liked Seamonkey, but it has its problems, so it is back to Firefox. The "new" Opera is not available for Linux, and it doesn't look like it will be available for Linux. Just as well as it is little more than a Chromium/Chrome clone.

Because of the way it does (NOT) handle HTML mail? This is the one thing I don't like about it, everything else is great, I think. Regarding Seamonkey Mail vs. Thunderbird: They are pretty much equal, aren't they? Of course, there are more extensions/add-ons/plugins for TB. On the other hand, I like the UI of Seamonkey more. And, BTW, Seamonkey sucks up less resources than FF+TB, when they are running simultaneously.


As you said in your previous post this is mainly a problem, if you use Konqueror outside of KDE. Within KDE it is relatively efficient, as the components it loads, such as KWallet, are also used by other KDE programs, such as KMail. So, in KDE these components would be there anyway, most of the time. Starting Konqueror in KDE therefore doesn't suck up overly much additional resources.

One problem I am aware of is, that with every update some plugins/add-ons/extensions are broken. In most cases I wouldn't care, but the calendar (Lightning) must work. Period. If I cannot rely on it, I cannot use it.
Now, that's something I am not too happy with. But it's virtually the only problem I found. Should I be aware of more/others?

The fate of Opera is a bit of a tragedy. I liked Opera very much a few years ago, when it came bundled with M2, the email client. The concept of "virtual folders" is still to be considered highly innovative and unique. Unfortunately they stripped off the email part and sold it. I wish them luck, but I am not using Opera anymore. Why should I use an incomplete clone of Chrome or Chromium, when I don't even like the original? ;)

gargamel

Yes. I can't remember the last time I received a plain text e-mail.


There some minor differences, but Lightning currently does not work with SeaMonkey. That could change.


Considerably less. Good point.


Agreed.