On this day of October 3, 2024
My first article was posted on Hacker News on Tuesday afternoon. I expected maybe a few hundred views but my naivete was quickly revealed. In the first hour, I got about 70 views and I figured that it might persist for a few hours and then die down. Much to my surprise, the view count started climbing like crazy, reaching a peak of 600 views per hour. The view count surpassed 10,000 in 37 hours. It is now reaching 12,000 and not showing any sign of stopping.
What is even more interesting is the level of engagement, meaning hits on my website (6%), hits on the installation walkthrough (0.7%) and hits on the Kraker download page (0.15%). The ratio of one potential customer per thousand tire kickers continues to hold true. Of course, the ratio will improve over time because, right now, I'm a total nobody. Also, a few people complained about the article presentation. One person said the article was "hard to read because of the bad formatting". I inquired and was informed that the article fills the width of the screen on a wide-screen monitor. Yes? Am I supposed to decide how wide your reading space should be? I honestly don't know what to do about that. Another complained about the "horrendous color scheme". I'm not inclined to ask why in this case because one person's favourite colour is another person's nightmare. I don't like white and I'm glad that the walls in my house are painted beige. Brownish tones are, I think, a nice compromise between white and black. I dunno. Still thinking about it. My repository for Alleycat Player has collected a few stars. It's been on hiatus for 2 years and I will get back to it soon. My problem has been the total lack of engagement in the past. Why bother if literally nobody cares? Part of the issue has been, in my opinion, the need of a local proxy server so that the player can do its magic. Much resistance to that which is what this flurry of article writing is about. Web Scraping with your Web Browser: Why Not?On this day of September 28, 2024
I've decided to write a series of articles on web scraping. The introduction includes working code. You will not be required to install anything except for a small template (I wrote some HTML and CSS so that you won't have to).
Web Scraping with your Web Browser: Why Not?On this day of September 22, 2024
The view counter on this page keeps counting up but I'm seeing little evidence that anyone is installing the local proxy server. There's a view counter on the Kraker download page and I put a hidden counter on the installation walkthrough. I can pretty much count the views on the digits of my hands and feet. Why is that? Who is bothering to visit this page without bothering with anything else?
I've been monitoring the hits on my remote proxy server with the Vercel control panel and I'm not seeing any hits from theOn this day of August 19, 2024
Whew! I've finally done it! I've released the latest version of the
On this day of August 13, 2024
Sigh. I've been battling YouTube because of IP address blocking and rate limiting. My own proxy server is blocked permanently because it resides in an Amazon cloud. The substitute proxy works but it gets rate limited. When that happens, the YouTube Player just won't work until the rate limit is lifted. The new plan involves upgrading my proxy server so it can work through a socks5 proxy to hide the Amazon IP address. The upgrade is done and working wonderfully. I have managed to find a handful of socks5 proxies that I can use. Most of them are pretty unreliable but a couple are turning out to be dependable and fast. When the app opens, it picks the first proxy on the list which is the best one. If that stops responding or if it gets rate limited then the app will rotate to the next proxy on the list. Working good so far.
The problem with finding suitable proxies is that the majority are already blacklisted by YouTube. I might find 10 working proxies but only one will be usable. It's a tedious process though I have this really nifty proxy checking tool which will be one of the apps that you will get totally for free when I finally release my Kraker package. I don't know if any of you are anticipating the release but I'm getting spurts of traffic here. Sometimes there's no traffic for a couple of days and then there's a few dozen visitors. I don't know from where but it's nice to see.
In related news, I had to remove some of the U.S. TV channels from the Free TV & Movies playlist. The source is no longer working. There are three other sources available but they require the local proxy server to work. There is only so much that can be accomplished with a remote proxy.
On that note, some people might be wondering why I don't just write this stuff as a desktop app, free of the browser restrictions. Well, that sounds nice but it's just trading one problem for another. I'm already offering you a desktop app in the form of a proxy server so how does it make a difference to package everything as a desktop app? Besides that, my apps need support for graphics, networking and video playback. Where should that support come from? The support is already there in the web browser. I don't have to go searching for libraries to do what needs to be done. Despite the issues (and there are many), I think the browser is an excellent development environment. Besides that, cracking these websites often involves running Javascript which is easily done inside the browser but difficult and extremely error-prone otherwise. There are a few pirate sites that could only be cracked by running a modified version of the Javascript inside an iframe and extracting the video information by trapping an exit point. This would be impossible to do outside of the browser. So, yeah, there is logic in my insanity.
Anyway, thanks for visiting. There is more to come.
On this day of August 9, 2024
So I've been working on a new installation tutorial for the
All of these apps make use of a scaled-down remote version of my local proxy server. It is hosted by Vercel which, in turn, is hosted by Amazon. It is a simple matter to block the proxy by the IP address and a number of websites are doing this right now. I had a hard time finding a pirate movie source because the ones that I'd already hacked are blocking my proxy. Either that or the hack is too involved anyway to be workable with a remote proxy. This blocking is actually news to me and it must have started over the course of the past few months. Whenever I hack a site, I always check to see whether or not it is workable with a remote proxy.
On August 6, YouTube started blocking my proxy and the YouTube Player app stopped working. I got it working again by a stroke of pure luck. This story is a bit long so buckle up. It is very informative and it goes along with what I said in my rant further down this page: "The Internet is getting tougher and more user-unfriendly". Everybody wants to lock you in and part of the process is blocking what is called "headless apps". This means bots and scrapers which normally operate without human intervention. My own utilities are, of course, not headless but they appear as such to websites. Jealous website operators do not want you using unauthorized apps to access their sites. One way to block these evil apps is to block the IP addresses belonging to data centres like Amazon Web Services. This is easily done with a list of all the data centre IPs, as well as the IPs of all known proxy servers. Google has such a list since they've been blocking data centre IPs from using Google search for at least the past couple of years and now they're doing the same for YouTube. Cloudflare also has the list and many pirate websites are hosted there. I think there has been a pricing or policy change at Cloudflare and that's why these pirate sites are now blocking my remote proxy whereas they did not have that ability prior to, say, six months ago. So the problem that I had was finding another proxy server which is not blocked by YouTube.
A few years ago, finding proxy servers was not difficult. Alleycat Player offered five proxy servers before I built my own at Vercel. They have all disappeared except for "api.allorigins.win" which has somehow resisted whatever abuses took down the others. Unfortunately, that one was also blocked by YouTube so I was left with no options. The YouTube Player could not be fixed. Just prior to offering the app for free movies, I discovered that the source (thetvapp.to) that I was using for U.S. channels in the TV app is no longer accessible. It is blocked by a Cloudflare bot challenge. The challenge can be bypassed using the local proxy server but that is not possible with the remote version.
This is an excellent resource for finding pirate sites. There is this one interesting site (www.braflix.ru) which turned out to be somewhat more than just interesting. For one, it is a proxy for the previously mentioned site which is now blocked by Cloudflare. Secondly, not only is my remote proxy server not blocked but the video link itself goes through a proxy. I don't know why because the proxy is not needed. My app tosses away the proxy wrapper. What is important is that this proxy is not blocked by YouTube. Thus, the YouTube Player has been fixed though only partially. Age-gated videos no longer work because the new proxy does not accept the POST method. There were issues already with some videos not working because of the IP address mismatch between the proxy server and the user. Anyway, after all this I now find that "api.allorigins.win" is no longer blocked. I don't know why. It turns out that it is hosted by Cloudflare but so is the other one that I used to fix the YouTube Player. What's going on?
I'll end this long story with a note. The nature of the block is not that the YouTube server refuses to deliver the file. Rather, it delivers the file without the links to the video. This triggers the app to assume that the video is age-gated and so it goes through a different route which also turns out to be blocked in a similar fashion. So the remote proxy server works in one instance but not in the other. All of this works just fine with the local proxy server. I could be wrong but I'm assuming for now that the difference is the IP address and nothing more.
The new app retains the functionality that I introduced with the Free Movies app. The zoom feature is the same and I've included an additional level to the brightness control. The custom video control is unchanged. You can select 360p, 480p or 720p. You can load a playlist or save a playlist. The app should be able to load any playlist that you find on the Internet. The playlist is saved with just the channel name and the URL. That is, it cleans up the list, removing the other garbage that makes the playlist very hard to manage in a text editor.
On startup, the app loads a default playlist from the GitHub server. As protection from the psychotic copyright warriors, the playlist is encoded on the server. I already got hit once with a DMCA notice on Alleycat Player and I don't want to risk that again because the way it went down is that I had to delete and restore the entire repository. Of course, I have my own local copies of everything and backups on a file storage service.
The radio stations in the default playlist are mostly HTTP. Since the app is loaded from HTTPS, your browser will likely not allow HTTP audio or video because web browsers are becoming increasingly and more stupidly strict (for your safety, of course, and not because design by committee leads to total bullshit). You can, however, open the audio link in a new tab. This issue does not exist with the local proxy server.
Free TV & Movies Playlist -- go here for playlists organized by country -- YouTube Player
In unrelated news, my neighborhood is starting to look like a jungle again. All of the gardens are overgrowing the walkways. Trees are growing where there were no trees. It's crazy. The threat of carbon dioxide is not global warming but the prospect of being buried alive by excess vegetation.
On this day of July 31, 2024
I'm here to drop another gift, this time offering some new movies to watch. It's similar to the Free TV app that I posted last time but for movies. I invested quite a bit of effort on finding a source that doesn't need the local proxy server because most of them go out of their way to prevent somebody like me from bypassing their shitty websites infested with popups, adware and malware. Some of them block certain IP addresses that belong to data centres which are often used for web scraping. Or they may hide behind a bot wall, courtesy of Cloudflare. Anyway, I've got a list of 16 recently released movies to entertain you for a while.
There is a particular issue with watching movies on a PC with a web browser. This issue is High Dynamic Range (HDR) versus Standard Dynamic Range (SDR). HDR has to be supported by your monitor and video card and maybe the browser in order to work. I don't understand the details but it's a big mess. What little research that I've done on the issue indicates that there are a LOT of problems even when you have the hardware and software support for HDR. There are conflicting standards and the support could be of such low quality that it hardly improves the viewing experience. For me, I have an old system with a CRT so I'm far from venturing into HDR. I'm kind of clueless.
What I do know is that you can tell when a video is intended to be viewed as HDR when it comes up very dark and over-saturated. I don't know if the pirate sites are actually dishing out properly encoded HDR or just SDR transcoded from HDR. I'm not familiar with the process of how they rip the content from the official DVDs or streaming sites. In any case, watching movies on a non-HDR system can be an exercise in misery but it doesn't have to be. While it is not an ideal solution, it is possible to brighten and desaturate the video to make it watchable. That is, the video can be balanced using the brightness, contrast and saturation settings in CSS. Unfortunately, gamma is not one of the options and it would be a lot better with gamma but we can get most of the way to something tolerable. A full solution would require tinkering with the video at the pixel level.
I have provided a single option in the app to brighten the video and it is a solution that will work satisfactorily most of the time. Dark areas may still be too dark and bright areas will definitely be too bright but this is the best that can be done. At least you'll be able to see what's going on and you won't be worrying about it much if the movie is any good.
Another issue is the super-wide format which is only suitable for theatres. It is horrible on a 4:3 monitor and annoying on a 16:9 monitor. I've added an option to zoom the video to fit the vertical space. Obviously, this will crop the video horizontally but you will barely notice. These two options, zoom and brighten, are not available anywhere else so I command you to enjoy this limited-time offer.
Free New Movies (link is dead)
On this day of July 14, 2024
On this day of September 29, 2022
So I have a new version of the
I discovered that, contrary to my expectations, the last version of the Bread Launcher does not work on Chrome-based browsers (I use Brave for testing). Works just fine on Firefox and that's what I use. Mozilla isn't a bitch trying to piss all over developers like the Chrome guys. I don't know how much influence Google has on Chrome development but I'm certainly not willing to give them the benefit of the doubt. It smells like Google has something up their sleeve with this obsession with third-party cookies.
But I'm getting ahead of myself. The problem with third-party cookies is that a lot of websites use them indiscriminately to track people around the Internet. I'm not seeing what the big deal is since browsers are already blocking trackers of all kinds so why don't they just block these suspicious cookies? Instead of doing that, Chrome is going for the big guns and killing third-party cookies altogether. They've been talking about this for a while but I haven't paid any attention because I didn't really care. Now I care because it's causing me grief with the Bread Launcher and the cookies that 8kun is using for the captcha. Firefox is not fussy about third-party cookies so it works fine but Brave is being a bastard. I wouldn't mind so much if I could use a site permission to get around the issue but, nah, no soup for you. Why not?
The whole motivation for developing the proxy server for
I'll tell you why. They think you are too stupid to be trusted. They think you'll get scammed by some Nigerian prince
with a money problem and that he'll convince you to install something that fucks up your system. What else could it be?
I can't have a checkbox for my apps because they think I'm stupid. Quite frankly, I don't care all that much if other
people use my apps. I just want to build them how I want and not have to bend over backwards because of browser
restrictions. This is the sort of shit that leads to workarounds like extensions (which they want to block too)
and my
Enough ranting. I love my proxy server and I don't want to be without it. Whatever the cunts at Mozilla and
Google decide to do, I'll find a workaround. Anyway, the issue with third-party cookies being blocked on Brave means
that full functionality isn't possible without faking an
In order for all of this to work, the browser needs to proxy all content through the proxy server. It's the only way. The bonus is that you get a great DNS manager and other features as part of the deal so it's not like you'll be tied down to the proxy just for the sake of using one or two of my apps. Besides that, you'll be planning for the future. Whatever happens to the Internet, I'll be here countering the totalitarian tendencies of our overseers.
On this day of August 1, 2022
I just completed the final touches on the documentation for the
I hate (HATE!) the Cloudflare bot protection. In the case of an HTTP connection, it is no protection at all, really. I discovered that Cloudflare looks at certain header names for proper case usage. The affected headers are: Host, User-Agent, Accept, Accept-Encoding, Accept-Language and Connection. I wrote some code to correct these headers and put them at the beginning of the header stack.
Header names are converted to lower case by Node.js and this makes sense since the HTTP specifications state that case in header names is not significant. It also makes my code easier to write since case does not need to be considered. A server is not supposed to reject an HTTP transaction based on the case of header names but we're not talking about normality anymore. It is war out there and Cloudflare is determined to win no matter what sort of inconvenience that incurs. Ignore the specs? Sure, why not? I shouldn't be having to do this.
My main target is
The problem with HTTPS is the negotiation (or TLS handshake) that is needed to establish an encrypted connection. The negotiation protocol is open-ended, meaning that there are a million ways to do it. This means that the specifics of the negotiation can be used to "fingerprint" the incoming connection. In much the same way, browsers can be fingerprinted based on the details of HTML rendering. So Cloudflare takes a fingerprint of the TLS handshake and will reject the connection if the handshake doesn't look like it is coming from a web browser. This is a big deal because it locks out Node.js and, really, any tool which is not based on browser code. It locks out non-transparent proxy servers so banned.video cannot be accessed through a corporate proxy and I don't know why Infowars doesn't care about that customer base. For that matter, I don't understand what the problem is in the first place. It's been like this for two years but I never heard of a bot attack on Infowars. I'm sure they get attacked from time to time but sheesh.
There are actually very few sites that do this. Most of the ones that I have seen are pirate video sites. That seems
to be a pattern since Banned Video is also a video site. It suggests that web scraping might be the issue and not
any kind of attack. Whatever. I can't figure out how to get into the site. There is no bot challenge, just a hard
stop. There is currently no tool to modify the TLS handshake in Node.js and this seems to apply across the board
though it apparently can be done with Golang (also known as Go). In any case, I'm not inclined to bother with trying
to solve the Cloudflare bot challenge since I'm not even getting that far with the sites that I want to hack.
Whatever. This is
The HTTP Toolkit guy has more info here. (Note: his advice on bypassing the fuckery is outdated. Unfortunately.)
News item for June 13, 2022
Kraker v4b is now available. This is a code fix (see my June 11 rant). It is a truly powerful proxy server that goes way beyond the needs of Alleycat Player (which still does not require a Kraker version later than the first one). The Kraker proxy is a product that now stands on its own merit and not just as an addon for the player. It is likely the most powerful proxy server designed for personal use. I just need to figure out how to attract some attention to it. As it is, very few people know or care. Well, that seems to be true for all of my software projects since I have started working on them.
Funny thing happened. There are two projects in my archive.org repository that suddenly got a lot of attention without any action on my part. The Black Box project (old BBC TV program) has 5 stars and almost a thousand page views. I have no bleeping idea where this interest came from. My Europa project has 15 stars and is nearing 5000 page views. The interest started around February and it might be because of a comment to a Youtube video (no idea what video). What does this mean? Should I get an account on Youtube and start posting comments? Like where should I post to get traffic to this site? Meh. I don't relish the idea of running around promoting this. Fame isn't my goal and I'm not sure that I really want to manage a horde of curious people who don't have the mental capacity to understand what I'm offering. Not that I think people are really stupid. It's just that most of them make no effort to understand something before trashing, commending or criticizing. I'm not a cat herder.
On this day of June 11, 2022
Time for a rant. This is about Node.js which is the development tool that I use to implement the Kraker Local Proxy Server. I have one favourable comment about this tool: it works flawlessly once you figure out what to do and what not to do. So far, no mysterious crashes or hangups that can't be traced to something that I did "wrong". On the other hand, the documentation is FUBAR (fucked up beyond all repair). Half of the specs don't actually apply, perhaps because the tool has gone through too many revisions. Event handling is the biggest headache. Also, it is difficult to understand where memory leaks come from because important stuff like proper socket destruction is barely touched on. You are given the impression that everything just works so you don't need to worry your little head with picayune details like "did I close that socket properly or not?". The biggest snafu is the HTTP Request module. What a mess. Important revisions took place with Node.js v13 and v16 that aren't documented. You're just supposed to know about them by following the developer forum, I guess.
These revisions are anything but minor. They are code-breaking and figuring out how to get around that can involve a lot of experimentation to find the differences so that the code can be reworked to compensate. With v13, the timing of some events was changed. When an HTTP transaction is passed down from the HTTP server, there are two forks: the request fork and the response fork. The first one receives the headers and data FROM the caller while the second sends the headers and data back TO the caller. It's a good division of labour and I'm not complaining about that. The difficulty lies in knowing when one or the other has completed processing. This is what events are for. They signal when something important has occurred. Now, don't get me wrong. The changes in v13 are justified and I'm surprised that it took so many versions between 10.0.0 and 13.0.0 to figure this shit out.
The important difference for me is that the response fork emits a "close" event in v10 only when the response is aborted (usually because the destination server closed the socket). In v13, the event is emitted always when the response completes. Big difference if your code is relying on the event to detect an aborted as opposed to a completed transaction. Another change occurred in v16. An aborted HTTP transaction no longer closes the underlying sockets. This is a biggie and I can't understand why they made such a change so late in the game. This behavioural change should have been made optional because it is abso-fucking-lutely code-breaking. I wasted several hours of my time trying to figure out an elegant solution to this which won't break compatibility with earlier versions. My code is designed to be compatible with all Node.js versions from v10 up to the latest version. I need to carefully craft the code to handle any discrepancies between versions. I refuse to be put in the situation of having to inform my users that, hey, you should upgrade your copy of Node.js because I'm too lazy to fix my code. I just don't operate that way unless I can find no other alternative.
End of rant. I'm quite pleased with the final outcome. I have finally rid the code of all traces of memory leakage (crosses fingers). My goal of maintaining a memory footprint of around 15MB seems to have been achieved. Now, this is actually pretty important. I have read many complaints about excessive memory usage and I have no doubt that this is due to a lack of understanding of how Node.js handles events and socket closures. The horror stories of Node.js apps consuming hundreds of megabytes can be traced to these memory leaks. It's the same problem that I've been struggling with over the last few versions of my proxy server app. When I first built the proxy, it was only for the sake of Alleycat Player so the actual usage was low and thus the opportunity for memory leaks was low also. With the inclusion of the Socks5 proxy, DNS support and other features, I now have ALL activity from my web browser streaming through the proxy server. Memory leakage is therefore a more important issue than it was.
Granted, the browser consumes 20 to 50 times the memory but I'm a stickler for perfection. Anyway, if you're a budding amateur developer who has dabbled with or is planning to dabble with Node.js then you should think seriously about carefully studying my code. It might help you to understand what you're doing wrong before you do it. Good luck and please don't hesitate to drop me an email with any questions you may have. After all, what is the point of doing what I'm doing if it is not to help someone (hopefully a lot of someones)?
News item for June 9, 2022
Oh my goodness! The DMCA notice references the blobs in my repository rather than the canonical paths. What this means is that modifying or deleting the files makes no difference. I would need to install a tool to prune the GitHub history tree to removed the blobs. If you don't understand what I'm talking about then join the club. I ended up deleting the entire repository and rebuilding it because that was easier than figuring out how to delete the history or the blobs or whatever it is I was supposed to do. I hope this doesn't happen again.
News item for June 7, 2022
Wow! Got hit with a DMCA notice today. This affects versions of Alleycat Player from v4b to v5b. Corus Entertainments doesn't like having their free Global News feeds passed around the Internet. A great many IPTV playlists are affected all over GitHub. For the time being, I have removed all of the affected copies of Alleycat except for v5b from which I have removed the Global News link. I'm thinking of using a simple algorithm to obfuscate the link so that Corus won't be able to find it again. They're obviously just using a simple string search to find the links. Obfuscation won't work for all of those playlists though. The DMCA notice lists a few hundred. Geez, what a needless headache for the GitHub management.
The DMCA notice is here: Plain Text or Rich Text Format
News item for May 15, 2022
Oh man! So long since I've typed something here. I just finished a massive update on the Kraker Local Proxy Server instruction manual. There is a LOT to document with the new update to version 4a (and I still have a few more things to cover but this is enough for now). Kraker isn't just a side tool for Alleycat Player anymore. It's now in the big leagues and deserving of some kind of an award. If I do say so myself, kek.
Anyway, I'm tired right now but I'll be back soon to post my thoughts. Stay tuned, fren.
News item for November 17, 2021
Alleycat Player will be two years old on December 7. Hard to believe that it's been that long. As noted on the main page, the installation and user manuals have been updated. This was way overdue and I've had to really drag myself to the task after leaving it aside for over a year. Now it's done and I can kick back with quart of tequila and celebrate all the hard work I've put into this. Hope somebody appreciates it. Later.
News item for October 13, 2021
I had to upload a new update for the 8kun Bread Launcher because I found some issues with Chrome-based browsers. The problem is that Chrome is a dog at opening new tabs and preparing the DOM. It reports that it is ready when it is not. This forces me to place extra checks and timeouts to make sure that the DOM is actually ready to be modified correctly. If I don't do this, I get the wrong values for things like the width or height of an element. This causes two problems when opening a new tab: the title in the status bar may not appear and images may be placed on the wrong side (the right instead of the left).
Another thing is that Chrome is stubborn about timers running in a page. It wants to slow them down when the page is in the background. That's fine. I understand how some web developers will abuse timers. However, a timer should only be slowed down if it consumes a lot of CPU. The auto-update timer in the Launcher does not consume CPU until it hits zero. There is no good reason to slow it down but Chrome is dumb and stupid about it. Anyway, the solution is to move the timer out of the main page and into the daughter page (because the main page is running in the background). It's just one line of code. Chrome will only slow it down if the daughter page goes to the background. Which is still wrong but it is at least tolerable.
News item for October 9, 2021
I am pleased to announce that the 8kun Bread Launcher finally supports posting. This is just a preliminary update. The posting feature is not yet full-featured but that'll come in the next week or so. Barring head-scratching complications, of course, and I've had a lot of them with this update. HTML and CSS never cease to present me with browser compatibility problems. For example, it turns out that Chrome browsers put a little blank space below the <textarea> element that should not be there. I had to hit the Internet to find a solution which was to add the setting "vertical-align:top" to the CSS for the element. Really??? Why do these things happen? Oh well. At least we are past the bad old days of Internet Explorer and Netscape.
Something is totally buggered with the "XMLHttpRequest" component. This is used to implement the posting operation. I could have used "fetch", which is what I would normally do, but I wanted to implement an upload progress indicator and that is not possible with "fetch". I got the indicator working but it doesn't actually work. I know it doesn't work in Firefox and I haven't bothered to test with the other browsers but my research on the net seems to indicate that this is a problem all around. The problem is with the "onprogress" callback which doesn't fire at regular intervals and often indicates the wrong amount of progress. I mean, it'll jump to 62% done right off the bat and then not fire again. Shit like that. Oh well, at least the uploading works.
On this day of September 17, 2021
I encountered a peculiar artifact while I was revamping the HTML for the Alleycat main page. My goal was to keep the text in a panel separate from the image in the same panel such that, if you zoom in (or if the user forces a larger font), the text won't wrap around the image as the panel expands vertically. Also, the image will remain centered. The only practical way to achieve such is to use a table format. An odd thing happened due to the inclusion of a table inside the panel. A 5-pixel-tall space appeared below the bottom border of each panel.
It was not my CSS that caused this spatial displacement. There was absolutely no reason for it and the artifact appeared in different browsers. In Firefox, the spacing varied by a pixel (arrgh). Originally, the panels were constructed with a <div> tag so I simply built the table inside the div. Removing the div and transferring the CSS to the <table> tag cleared up the problem. I have no idea what went wrong but I guess I should be happy that it is now fixed.
I have a similar issue with Alleycat Player and it may be due to the way the table format conflicts with something else in the video viewers. All three viewers should be displayed exactly the same but they are not. There is one out of the three which has a slight difference somewhere. This varies with different browsers. It's been months and I still can't figure it out. Grrrrr.
Addendum: After writing the above, I discovered something else. The problem was caused by declaring "display:inline-block" in the CSS for the div. The artifact goes away with "display:block". Alternatively, the declaration "vertical-align:middle" also works. Why???
News item for September 15, 2021
The