Threatening mail by Yellowtab

Update 2005-08-20, 14:53:

The comments in the german BeOS user group website forums that are linked in the update below have been deleted by Ralf Schülke, an other admin of that website. They have NOT been deleted by Bernd Korz. Ralf Schülke said in chat that he did this in order to keep the website clean, and due to (but not on behalf of) the person who posted those comments. Quote: "das die debug solange wie ich da was entscheiden kann, auch sauber bleibt" and "er macht nur Ärger".

Update 2005-08-20, 14:16:

Nothing related to AVM, ISDN, DVB-T or SATA development that is described in this blog is covered by a NDA signed with Yellowtab. In his email, Bernd Korz refers to another incidence that is unrelated to this blog, when threatening to sue me after he got angry about the AVM article I wrote.

Bernd Korz is admin of the german BeOS user group website, and of cause the Yellowtab.com and Yellowtab.de websites. Multiple comments posted there, which tried to link to this blog, have been deleted. Some of them are mirrored here:

My original posting in the Yellowtab.de forum AVM thread (HTML)
One posting in the Beusergroup.de forum (image)
A new thread in the Beusergroup.de forum (image)


Original article 2005-08-19, 20:28:

After I read the third comment to the previous blog posting yesterday morning, I was fairly sure that it had been posted by Bernd Korz, the one mentioned in the article. The comment is the one that starts with "One of that projects you started and never finished. Well you are such a person." The phrases used, typical spelling mistakes, background knowledge that shows through, omission of facts, date and time of posting, etc. everything seemed to indicate that it was written by him. Judging other comments and responses, many people assume the same. I wasn't sure if it was really him, because I thought that he wouldn't be so mad at me to do such a nutty thing like posting the comment.

I didn't contact him, and I didn't ask. But I noticed that the single comment as pointer to the blog article, that I had left in the original thread at Yellowtab forum, had been deleted at about the same time.

Well, yesterday evening I recieved an outrageous email from Yellowtab, written by their CEO/CVO Bernd Korz. Now I'm even more sad about Yellowtab's behaviour. Threatening me in such a perfidious way, while at the same time selling Zeta, which contains drivers that I wrote for BeOS and were available free of charge.

At the beginning of the mail, he denies to have written the comment in my blog. Then he acknowledges to have deleted my comment in the Yellowtab Forum. He goes on by explaining that he had to pay for the hardware that AVM provided. After that, he says that he has no interest in what I do, write or post, and that he doesn't want to deal with me anymore, pretending to speak for all Yellowtab developers.

Now the ugly part starts. Using an alleged NDA (non disclosure agreement) breach, he promises to undertake everything that is possible to sue me. He claimes that even this mail is protected by the NDA that I signed with Yellowtab, but I'm certain that it doesn't apply here. At the end, he says that a copy of that mail was sent to their lawyer, who is now checking legal measures against me.

I don't know why he payed for the AVM hardware, but as far as I remember, it was provided by AVM as a loan. I still keep the two cards that I got in save custody. When I last inquired at Yellowtab about two years ago how I could return it, I was told that there was no need to. Still, paying for hardware is no reason to not do business, or to act crazy like this.

I understand that details like this don't look bright for Yellowtab. But I spent much time with development of BeOS software and drivers, and I really don't like to be threatened like this after all what I did. Yellowtab is acting very very treacherous. If you want to deal with them, keep their mail in mind.

I think I provided much benefit for Yellowtab during the last years, by developing software, and also by testing and reporting bugs. Some got fixed, most didn't. I was also busy getting DVB-T to work on Zeta, but I'll stop that now, and make sure that it will run on BeOS R5 and Haiku, but not on Zeta.

There is only one secure way to prevent an email from beeing published: don't write it. The complete and unaltered mail is reproduced below.

Date: Thu, 18 Aug 2005 19:06:02 +0200
Message-Id: <20050818190602.3878.3@mulsum.yellowtab.home>
From: Bernd Korz <bernd.korz@yellowtab.com>
Subject: Posting
To: marcusoverhagen@arcor.de
Cc: sonja.bauer@yellowtab.com

Hallo Marcus,

auch wenn es den Anschein hat was das Posting auf deinem Blog angeht so ist es nicht von mir. Was ich getan habe ist Dich auf dem yT.com Forum zu sperren und ich habe auch Deinen Beitrag dort gelöscht.

Ich weiss nicht was ich oder yT Dir getan hat aber ich denke wir waren immer Hilfreich. Falls Du es nicht weisst: ICH habe damals die gesamte Hardware an AVM bezahlen müssen. 1500 Euro und ich habe zu der Zeit GAR KEIN GELD gehabt. Ich habe es monatlich abbezhalt.

Warum auch immer Du so bist wie Du bist, Du wirst Deine Gründe haben. Mich interessiert es nicht wirklich. Was auch immer Du postest oder machst oder nicht machst, auch das interessiert mich nicht.

Ich will Dir nur sagen das ich mit Dir nichts mehr zu tun haben möchte, und hier spreche ich auch im Namen ALLER Entickler von yT. Du hast schon als Betatester Deinen NDA gebrochen weil Du so vergrellt bist und nun wetterst Du schon wieder, das ist sehr sehr schade denn ich denke wir haben uns wirklich bemüht Dir zu helfen.

Ich lasse gerade rechtlich prüfen in wie weit wir gegen Dich vorgehen können. Auch deshalb weil Du ja den NDA gebrochen hast. SOLLTE yT die Möglichkeit haben Dich zu verklagen so kann ich Dir versichern das ich ALLES daran setzen werde das es passieren wird. Denn Du spielst ein sehr unfaires Spiel und ich werde dem nun rechtlich entgegenwirken.

Diese email ist unter NDA und ich hoffe das Du nicht schon wieder den Fehler machst und es veröffentlichst. Ich habe diese email als CC an unseren Juristen geschickt der gerade rechtliche Schritte gegen Dich prüft.

Bernd Thorsten Korz
CVO/CEO yellowTAB GmbH

ISDN drivers for AVM B1 and Fritz cards

Today I read a few postings in the Yellowtab forum which reminded about my project to write an ISDN driver for BeOS.

For those who can read german, the complete thread is here. In a nutshell, Bernd Korz, CEO of Yellowtab, is publically saying they have been geschädigt und verarscht genug (been harmed and spoofed enough) by AVM, and that there won't be support for AVM products in Zeta for at least the next 20 years. AVM is the manufactorer of ISDN and DSL hardware.

It was in 2001, Yellowtab was just founded, Be Incorporated was still in business and busy developing BONE (BeOS new network stack), and there was no Zeta yet. BeOS R5 was still using net_server, but I was on the BONE beta program, and had access to both. Be Inc had released a beta driver for AVM B1 cards (which didn't work for me), but it was rumored that they had no permission to use the sourcecode from Marco Borm on which it was based on. At that time Marco Borm made his sourccode public, and Be Inc never ever updated their driver.

After I talked with Bernd Korz about it, I decided to try again writing a ISDN driver for BeOS. AVM provided four ISDN cards for development to Yellowtab, two active B1 cards, and two passive Fritz cards. I got one of each. My intention was to get the simple active B1 card working first. Useful documentation for the B1 card was made available, too.

The project progressed pretty fast, and after a few weeks, the card specific driver was finished. Dialing a provider's telephone number worked, and PPP frames were transmitted into both directions. I was pretty happy.

Unfortunately, net_server did crash pretty easily when dealing with PPP frames received from ISDN, and a handshake never worked. Obviously, the net_server PPP stack didn't support the synchronous PPP as used with ISDN, while it did support asynchronous PPP as used with modems.

Because of the ongoing BONE beta programm, I tried to interface the ISDN driver with the new BONE network stack. There a huge bug emerged. BONE was using 100% CPU at a very high priority when reading from the emulated serial port that the driver provided. The same problem did not happen with net_server, but it made further development pretty impossible.

To cut a long story short, it was impossible to get any support from Be Inc. that would allow to solve the problem. Development was stalled. Trying again with net_server seemed to be a bad idea, because it was meant to be replaced by BONE. Shortly after that, Be Inc went out of business, and any further development wouldn't have been useful for me. In fact, now that Yellowtab is selling Zeta, I don't even have ISDN anymore, as I'm using DSL.

When development was cancelled, I passed all sourcecode to Yellowtab, hoping they could one day continue it. Now that they are developing Zeta, and seem to have all the sourcecode for the OS, I think it should be pretty simple for them to get the AVM B1 driver that I wrote to work with Zeta's network stack, which is BONE. But the comments made by Bernd Korz in the Yellowtab forum show a completely different direction.

I think Bernd Korz is acting very childish here, and not like a business person. I can truly understand why AVM doesn't like cooperating with Yellowtab anymore. In 2001, AVM gave cards to Yellowtab, but without return. A stable BeOS AVM B1 driver never got published.
I don't know what happened recently between Yellowtab and AVM. But a company's CEO who gives negative statements like this in a public forum isn't someone you can deal with and do business.

Beeing the single developer who, closely cooperating with Yellowtab and supported by AVM, tried to help bring ISDN support to BeOS in 2001, I'm very sad about this outcome.

I really regret having been involved with Yellowtab in this case, because AVM has probably blacklisted my name by now, due to the fact that Yellowtab doesn't behave in a businesslike manner.

Good news everyone!

Last week Yellowtab sent me a updated media_server for Zeta 1.o which appears to work reliable with DVB. In the meantime, Yellowtab has made it available on their homepage, which is good for those who want to use eXposer, which was suffering from the same problem.

I also managed to get the AutoStart function working, so the DVB TV applications can use BMediaRoster::GetLiveNodes() now, and don't need some strange workarounds. It turned out that the prototype for the BMediaAddon::AutoStart() as described in the BeBook is wrong. One parameter is specified as int32, but must be an int, as done in the header file. Due to wonders of C++ name mangling, and int32 beeing defined as long on BeOS, that tiny difference is enough for the AutoStart function to get another internal name, resulting in not beeing called by the OS.

I mailed an updated DVB media-addon to Pascal today, so he can hopefully use it on his Zeta 1.0 system now for further DVB-S development.

media_server crash, and more information on live nodes

It's verified now. Zeta 1.0 media_server does crash when using the DVB media add-on. Exactly the same crash occurs when quitting eXposer. This seems to be a new bug that was introduced with release of Zeta 1.0, as it doesn't happen with the previous release, Zeta neo. It seems as if during final quality testing before Zeta 1.0 release, nobody tested eXposer. Too bad, I hope there will be an update or service pack available shortly.

I also received a reponse from Yellowtab's current media kit guy, Maurice Kalinowski. Unfortunately, it appears that the media kit doesn't make all physical input and output nodes available as live nodes, so the application has to do a little more than I expected. The complete answer is reproduced below, I assume the answers will be helpful for some of you.

Dear Mister Overhagen,
on August, 6th you have contacted me because of some issues regarding the MediaKit, especially for your work on the DVB interface. I hope the following answers will help you on your activities.

1)
Notwithstanding the use of B_FLAVOR_IS_GLOBAL in the flavor_info::flavor_flags field, media kit allows to instantiate more then one node for the flavor, and calls InstantiateNodeFor whenever BMediaRoster::InstantiateDormantNode() is called for the flavor. I also set flavor_info::possible_count to 1, but that doesn't help either, so I had to revert to a very ugly workaround.
Question: What do I have to get it working right, i.e. preventing further calls to InstantiateDormantNode() after the flavor got instantiated the first time?

Currently B_FLAVOR_IS_GLOBAL only checks wether the Node should be loaded into the Media AddOn Space or into your applications one. So it seems like BMediaRoster is instantiating additional nodes although it was not supposed to do this. I will check on this... But I am really interested in your workaround, although being ugly as you said.

2)
The flavors and nodes that are instantiated have the kind B_PHYSICAL_INPUT, I assumed that all physical input flavors would be instatiated automatically at media server startup, so that applications can find them with BMediaRoster::GetLiveNodes(). However, when having two DVB cards in the system, only the first flavor is automatically beeing instantiated, and available as live node. The BeBook says: "An active node is a node that is preloaded by the system and is always available for use, as opposed to a dormant node, which resides in an add-on and is only loaded when instantiated using InstantiateDormantNode(). "
Question: Under what conditions is a node beeing preloaded, and why is only one of my BMediaAddon flavors (nodes) beeing preloaded?

During the start of the media_server it scans the media preferences, which input is set as the default one. Afterwards this input gets instantiated and available as LiveNode. The fact, that this input is supposed to be the 'default' one, only this one got started, although there may exist multiple ones of the same kind.

3)
Question: Are all physical input / output nodes supposed to be active nodes and preloaded?

As explained in 2 only the default one set in the media preferences gets preloaded and active.

4)
If answer to 3 is "no",
Question: how should an application know which dormant nodes are already live, and which need to be instatiated? Why does the application has to care?

Until now, it just seemed reasonable that the user or the application only needs to use one physical input. This is the reason why an application should just request for the default and active inputs for audio and video. Your aspect of using multiple DVB or soundcard above is a good argument for possible changes on this.

5)
BMediaRoster has GetAudioInput() and GetVideoInput(), but these only return the interface selected in Media preferences.
Question: Whats the correct way for an application to handle multiple physical inputs, like 3 soundcards or 2 videocards?

This is the same point as in question 2 and 3. As you said GetAudioInput() and GetVideoInput() only gives you access to one media_node. This is the one selected as the default Input in the Media Preferences. If you want to use multiple inputs, you may hold the media_node_id and then use status_t BMediaRoster::GetNodeFor( media_node_id , media_node )

6)
I tried to use BMediaNode::AutoStart(), but it's never called. I'm returning true from BMediaNode::WantsAutoStart(). You can see a source snippet at addon.txt
Question: whats wrong?

I have tested something similar to your problem here in the company and it worked, so I do not really know, what might go wrong on your side. It would be great, if you may show me more of your code, so I can take a deeper look at this.
By the way you should use B_MEDIA_ADDON_FAILED in your AutoStart() function instead of B_ERROR if you want AutoStart to be called again for the next index. There is a typing error in the BeBook as it says B_ADDON_FAILED, but it is supposed to mean B_MEDIA_ADDON_FAILED.

7)
Question: When should a node use BMediaNode::AutoStart ?

A BMediaNode should only be autostarted if it is supposed to be available during the whole time a system is running. The best example for this is the Mixer as the user wants to listen to sound the whole time...

To come to an end I want to thank you again for telling us about your experiences with the MediaKit as it gives us an impression about what should be improved for developers.

Regards
Maurice Kalinowski

Recent events

This blog has now a wider audience, as it's URL got public yesterday. I hope it's interesting for you. Perhaps everyone doing any related development will benefit from this, at least I hope so.

Even Yellowtab noticed this blog, and I got the email address of a contact person for media kit related questions. They really do want to support developers, and they are also working on a more developer friendly website. Thats encouraging, and I'll keep you updated on the progress.

Furthermore, I had a few telephone calls with Pascal today, clarifying his problems. When he tries to use the DVB media add-on, his media_server does crash. I never have seen this problem before. An older version of the DVB media add-on was working well for him, but this was last tested in April and May.

I'm still using Zeta neo for DVB-T development, while Pascal is already using Zeta 1.0 for DVB-S driver development. He hasn't tested the recent add-on version with Zeta neo, and I haven't tested it with Zeta 1.0 so far. While I can't imagine whats going wrong, I'll have to run some tests using Zeta 1.0 at the weekend. However, whatever the add-on is doing, I don't think that is should be able to crash a system server process. If you are curious, here's the debugger output:

loading symbols
Buffer being recycled, but it is not in use!
_debugger:
_debugger:
+0007 e80635a7: * c3 retn
media_server:sc
frame retaddr
f8ffba80 90020890 MBufferManager::ReclaimBuffers(long const *, long, long, long) + 0000027c
f8ffbae8 90017258 _ServerApp::MReclaimOutputBuffers(BMessage *) + 000001a4
f8ffbdc0 90014e3c _ServerApp::MessageReceived(BMessage *) + 0000044c
f8ffbe40 e8170c96 BLooper::DispatchMessage(BMessage *, BHandler *) + 00000076
f8ffbe58 e8168218 BApplication::DispatchMessage(BMessage *, BHandler *) + 000007d0
f8ffc07c e81707ba BLooper::task_looper(void) + 000002a6
f8ffc31c e816617c BApplication::Run(void) + 00000068
f8ffc330 9001a7b4 main + 00000158
f8ffc4bc 900141e4 _start + 00000060
f8ffc4e8 f8ffc523 _end + 106cae73
media_server:

Bought a second DVB-T card

I got a mail from Pascal who is working on DVB-S. He seems to have some issues with the media add-on that I wrote, but only when using more than one DVB-S card. I was still using the single DVB-T card that I got from Hauppauge in November 2004, and thus wasn't able to reproduce anything.

Obvious solution was to buy another one, and after work I drove to MediaMarkt, where I picked up a new Hauppauge WinTV NOVA-T PCI card for just 79 EUR. This seems to be more expensive than ordering one for 65 EUR by mail, but you don't have to pay 15 EUR for s&h, and also it's immediately available. Good deal I think. It's the exact same card that I'm already using, model 928. Nothing new here, and is recognized out of the box, at least on my system :-)

After modifying the TV application to support multiple cards, it only found one live DVB media node, and thus only one card. Very strange. The media add-on supports an unlimited number, and has no restriction here. Zeta Media preferences shows both interfaces.

Turns out that Media preferences uses BMediaRoster::GetDormantNodes() to create the interface list, and instantiates those nodes that are not active when you select them. They are destroyed when it quits. My TV app uses BMediaRoster::GetLiveNodes(), as a the first DVB card always seems to be instantiated by the media kit. Finding a dormant node and instantiating it for the first card is not possible, it's already live.

I did assume that all physical hardware interfaces would be automatically instantiated and go live. However, the exact behaviour is not documented and the current behaviour is inconsistent.

I made a screenshot which shows two active cards, pretty nifty, but right now useless, as the audio decoder crashes pretty easily. When looking at the screenshot you may notice that you don't hear the audio, as the decoder crashed.

I also researched other ways to get all cards go live automatically, and there is BMediaAddon::AutoStart(), which never gets called, so I can't use it. Must be a bug.

Right now I'm using Zeta neo for development, and thus I tried the Yellowtab website, looking for a developer relations contact, bugreport form or other help, but didn't find any. The website only says "Developers are very important to yellowTAB. In this section you will find a collection of articles dealing with developing for the ZETA operating system." There you can find one article about the locale kit, but nothing useful for me. Also trying IRC chat with other developers, including one Yellowtab employee, didn't give me a clean solution, except putting a workaround in the (or: every) TV application, which I don't intend to do.

Multiple card support seems to be possible, but requires some ugly workaround in the TV application to instantiate those nodes that are not live.

It would still be good to find out how it's really supposed to work. If you know, please leave a comment.