- Welcome to Freebox Jukebox.
Recent posts
#51
General Discussion / Re: Video covers not showing
Last post by Barcrest - October 02, 2025, 12:07:38 PMWhat option do you have set? Are the covers named the same like cover.jpg or are you using first cover found? As I have not seen this reported before I suspect it might be something with how you have them set up. What do you have as default library? Also what .COV file do you have set for those libraies? Check they are using the same one as the audio and resave the settings after picking from the drop down and reload.
#52
General Discussion / Re: Video covers not showing
Last post by johnleo - September 30, 2025, 03:41:59 PMHi Barry yes its working on audio . i have the covers in the same folder yes and im also not getting any covers with karaoke.
#53
General Discussion / Re: Video covers not showing
Last post by Barcrest - September 30, 2025, 02:07:00 PMDo you have the covers in the same folder? Are you using a fixed file name such as cover.jpg and coversmall.jpg? Is it only the videos that are not showing covers, is it working on audio?
#54
General Discussion / Video covers not showing
Last post by johnleo - September 30, 2025, 02:04:47 PMHi is there anybody that could please tell me or point me in the right direction with Video & Karaoke not showing covers , i seem to be able to get the videos to play but it just says new on the selection screen till i click on it then it will display the song title but i have no cover showing on either video or karaoke files. its driving me nuts lol. ive been trying all sorts of combinations over the last few days but alas nothing has seemed to sort this problem out and im at a loss as to what to do next thus me humbly asking any of you good people for a helping hand if you would be so kind. many thanks in advance.
#55
Support and Bug Reports / Re: Freeplay Mode
Last post by Barcrest - September 30, 2025, 11:40:44 AMA Keyshortcut has been added for this in the latest beta.
#56
Support and Bug Reports / Re: Pause the jukebox
Last post by Barcrest - September 30, 2025, 11:40:07 AMCheck out the new beta. I went for the CAPS Lock option as i had already done some work on it. It was also much easier that adding some RS232 stuff. I could possibly implement the RS232 stuff but it is a lot of work and I am really only maintaining it and bug fixing right now. I can add things if they are easy enough to do but more complicated additions I am not sure. Hopefully this resolves some of the issues for you.
#57
Support and Bug Reports / Re: Pause the jukebox
Last post by fb28 - September 29, 2025, 03:38:49 AMGee, I hate to bug you, but another idea that may be easier
to implement:
To generate a status output (lock juke or anything else), you
can have the user get a USB serial port emulator device. Most,
if not all implement the typical RS-232 control lines. In our
case (output) you can use the RTS (request-to-send) or DTR
(data terminal ready) or both if there is a requirement for
an additional status output. Very easy to set up with WIN32
API...
As far as setup goes, back to the trusty registry. Add another
key to E-Touch 8 that you would put in the virtual com port,
default baud rate, etc., and what status signal (lock juke
for now) you want to associate with RTS, DTR, etc. Future
use could use the control line inputs as well. Save that
for another day. Since this feature would only be applicable
to the commercial operator, there's no reason to clutter up
the configuration screens/tabs with something rarely used.
The main benefit is that you won't have any potential sync
issue with toggling the Caps Lock key on the keyboard.
I realize this would not be for the "casual" user (who
shouldn't even know what a registry is, let alone dabble
in it..., and they would need some RS-232 to TTL (or
whatever) device to translate the USB com port signal outputs -
those are all over Amazon for next to nothing. Obviously,
they would need some electronic background to properly
interface any status signal with the coin/bill acceptor
enable lines anyway.
Hope this helps, and maybe saves you some work...
Thanks...
to implement:
To generate a status output (lock juke or anything else), you
can have the user get a USB serial port emulator device. Most,
if not all implement the typical RS-232 control lines. In our
case (output) you can use the RTS (request-to-send) or DTR
(data terminal ready) or both if there is a requirement for
an additional status output. Very easy to set up with WIN32
API...
As far as setup goes, back to the trusty registry. Add another
key to E-Touch 8 that you would put in the virtual com port,
default baud rate, etc., and what status signal (lock juke
for now) you want to associate with RTS, DTR, etc. Future
use could use the control line inputs as well. Save that
for another day. Since this feature would only be applicable
to the commercial operator, there's no reason to clutter up
the configuration screens/tabs with something rarely used.
The main benefit is that you won't have any potential sync
issue with toggling the Caps Lock key on the keyboard.
I realize this would not be for the "casual" user (who
shouldn't even know what a registry is, let alone dabble
in it..., and they would need some RS-232 to TTL (or
whatever) device to translate the USB com port signal outputs -
those are all over Amazon for next to nothing. Obviously,
they would need some electronic background to properly
interface any status signal with the coin/bill acceptor
enable lines anyway.
Hope this helps, and maybe saves you some work...
Thanks...
#58
Support and Bug Reports / Re: Pause the jukebox
Last post by fb28 - September 29, 2025, 02:07:17 AMForgot to mention...
If you are using the simulated Caps Lock keypress to control the LED,
Remember it's toggle (i.e. alternate-action). But so is the Lock-Juke
button (whatever key it gets assigned to). Both being toggle, there
might be a possibility that they could get out-of-sync. I suppose an
error check would be to test the Caps Lock function after the Lock Juke
was keyed in to make sure the LED followed the correct toggle state.
BTW, if you get time... The questions about the slider controls:
Is there a way to find out, or set, the spacing of the letters
when you click on page-up/page-down, etc.? For example, if
you wanted a larger nav slider gadget, with larger letters,
and obviously a larger "bubble" or square box, etc. as a
"pointer", how or where would you find the values that
define these?
Is there a way to put a slider control option
on the skintool dropdown for the Genre screen, in addition
to jump-to-letter?
I have seen some skins that have two nav
arrow buttons: one seems to scroll one-by-one, the other
advances full pages. Is this feature only available on
some pages/screens? What or where or how would it be
enabled?
So glad you're here to help...
If you are using the simulated Caps Lock keypress to control the LED,
Remember it's toggle (i.e. alternate-action). But so is the Lock-Juke
button (whatever key it gets assigned to). Both being toggle, there
might be a possibility that they could get out-of-sync. I suppose an
error check would be to test the Caps Lock function after the Lock Juke
was keyed in to make sure the LED followed the correct toggle state.
BTW, if you get time... The questions about the slider controls:
Is there a way to find out, or set, the spacing of the letters
when you click on page-up/page-down, etc.? For example, if
you wanted a larger nav slider gadget, with larger letters,
and obviously a larger "bubble" or square box, etc. as a
"pointer", how or where would you find the values that
define these?
Is there a way to put a slider control option
on the skintool dropdown for the Genre screen, in addition
to jump-to-letter?
I have seen some skins that have two nav
arrow buttons: one seems to scroll one-by-one, the other
advances full pages. Is this feature only available on
some pages/screens? What or where or how would it be
enabled?
So glad you're here to help...
#59
Support and Bug Reports / Re: Pause the jukebox
Last post by fb28 - September 29, 2025, 01:51:21 AMThanks for the update... So I guess the Lock Screen banner (Event in Progress)
no longer reacts to a click/touch and brings up the Now Playing screen? And maybe
you have a registry (the cheap and dirty way) entry where you can change the
"Event in Progress" to blank ("") or whatever label the operator wants? And
the last song played doesn't play again?
I'm happy you will implement the status output idea... Not sure how you
interface with the keyboard. Waaaaaay back when, I did a project where
the front panel of a device emulated a keyboard. Put a PIC uController
on it so a push of a button would generate a "keypress". Detected the
LED status from the PC (actually used a single-board-PC running embedded
DOS). Worked great, except DOS let me access the keyboard controller
hardware - I don't think it's the easiest thing in the Windows world.
I did however, find a Windows API out there in the ozone (might be
what you are already using). I tried to attach it (BYW, it's in C++),
but got a message the upload directory is full. So, see below...
Thanks again. I wonder up to now how the commercial operators handled
the pause/sleep mode and coin/bill acceptors? Unless they just power
off the machine.
---------------------------------------------------------------------------
On Windows, the HidD_SetOutputReport function is used to control keyboard LEDs by sending a Human Interface Device (HID) output report to the top-level keyboard collection. For standard keyboards, this involves setting a single byte in the output report to specify the state of the Num Lock, Caps Lock, and Scroll Lock LEDs.
The process for controlling standard keyboard LEDs
Obtain a device handle. You must first get a handle to the keyboard's top-level HID collection. You can do this by using the SetupDi... functions and then CreateFile with dwDesiredAccess=0 and dwShareMode=(FILE_SHARE_READ | FILE_SHARE_WRITE).
Determine the report format. To know the correct size and structure of the output report, you can use HidP_GetCaps. This function provides a HIDP_CAPS structure, and the OutputReportByteLength member tells you the required buffer size. For a standard keyboard, the report is typically 1 byte long (plus a leading Report ID if used).
Construct the output report. You will need to create a buffer that represents the output report.
If the report descriptor does not use report IDs, the first byte of the buffer must be 0.
If report IDs are used, the first byte must be a non-zero report ID that corresponds to the LED report.
The second byte (or the first, if no report ID is used) contains a bitmask for the LEDs.
Bit 0: Num Lock
Bit 1: Caps Lock
Bit 2: Scroll Lock
Example: A value of 0x03 (00000011 in binary) would turn on both Num Lock and Caps Lock.
Call HidD_SetOutputReport. Once the report buffer is prepared, you call the function with the device handle, the buffer, and its length.
Example C++ code using the HID API
cpp
#include <iostream>
#include <windows.h>
#include <setupapi.h>
#include <hidsdi.h>
#include <hidpi.h>
#include <vector>
// Link with hid.lib and setupapi.lib
#pragma comment(lib, "hid.lib")
#pragma comment(lib, "setupapi.lib")
void SetKeyboardLEDs(HANDLE hDevice, BYTE ledState) {
PHIDP_PREPARSED_DATA ppd;
if (HidD_GetPreparsedData(hDevice, &ppd)) {
HIDP_CAPS caps;
if (HidP_GetCaps(ppd, &caps) == HIDP_STATUS_SUCCESS) {
std::vector<BYTE> reportBuffer(caps.OutputReportByteLength);
// Set the report ID if the descriptor includes them, otherwise it's byte 0
if (caps.NumberOutputButtonCaps > 0 && caps.ReportID) {
reportBuffer[0] = caps.ReportID; // or the correct report ID
reportBuffer[1] = ledState;
} else {
reportBuffer[0] = ledState;
}
if (HidD_SetOutputReport(hDevice, reportBuffer.data(), reportBuffer.size())) {
std::cout << "Successfully set LED state: " << (int)ledState << std::endl;
} else {
std::cerr << "HidD_SetOutputReport failed: " << GetLastError() << std::endl;
}
}
HidD_FreePreparsedData(ppd);
}
}
int main() {
GUID hidGuid;
HidD_GetHidGuid(&hidGuid);
HDEVINFO hDevInfo = SetupDiGetClassDevs(&hidGuid, NULL, NULL, DIGCF_PRESENT | DIGCF_INTERFACEDEVICE);
if (hDevInfo == INVALID_HANDLE_VALUE) {
std::cerr << "SetupDiGetClassDevs failed: " << GetLastError() << std::endl;
return 1;
}
SP_DEVICE_INTERFACE_DATA deviceInterfaceData;
deviceInterfaceData.cbSize = sizeof(SP_DEVICE_INTERFACE_DATA);
// Iterate through all HID devices
for (DWORD i = 0; SetupDiEnumDeviceInterfaces(hDevInfo, NULL, &hidGuid, i, &deviceInterfaceData); ++i) {
DWORD requiredSize = 0;
SetupDiGetDeviceInterfaceDetail(hDevInfo, &deviceInterfaceData, NULL, 0, &requiredSize, NULL);
std::vector<BYTE> detailBuffer(requiredSize);
PSP_DEVICE_INTERFACE_DETAIL_DATA_A deviceInterfaceDetailData = (PSP_DEVICE_INTERFACE_DETAIL_DATA_A) detailBuffer.data();
deviceInterfaceDetailData->cbSize = sizeof(SP_DEVICE_INTERFACE_DETAIL_DATA_A);
if (SetupDiGetDeviceInterfaceDetail(hDevInfo, &deviceInterfaceData, deviceInterfaceDetailData, requiredSize, NULL, NULL)) {
HANDLE hDevice = CreateFileA(deviceInterfaceDetailData->DevicePath, 0, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL);
if (hDevice != INVALID_HANDLE_VALUE) {
HIDD_ATTRIBUTES attrib;
attrib.Size = sizeof(HIDD_ATTRIBUTES);
if (HidD_GetAttributes(hDevice, &attrib) && attrib.UsagePage == 0x01 && attrib.Usage == 0x06) {
// Check for Keyboard usage
std::cout << "Found keyboard: " << deviceInterfaceDetailData->DevicePath << std::endl;
SetKeyboardLEDs(hDevice, 0x01); // Set Num Lock ON (0x01)
Sleep(2000);
SetKeyboardLEDs(hDevice, 0x02); // Set Caps Lock ON (0x02)
Sleep(2000);
SetKeyboardLEDs(hDevice, 0x00); // Turn all LEDs OFF
CloseHandle(hDevice);
break; // Stop after finding the first keyboard
}
CloseHandle(hDevice);
}
}
}
SetupDiDestroyDeviceInfoList(hDevInfo);
return 0;
}
no longer reacts to a click/touch and brings up the Now Playing screen? And maybe
you have a registry (the cheap and dirty way) entry where you can change the
"Event in Progress" to blank ("") or whatever label the operator wants? And
the last song played doesn't play again?
I'm happy you will implement the status output idea... Not sure how you
interface with the keyboard. Waaaaaay back when, I did a project where
the front panel of a device emulated a keyboard. Put a PIC uController
on it so a push of a button would generate a "keypress". Detected the
LED status from the PC (actually used a single-board-PC running embedded
DOS). Worked great, except DOS let me access the keyboard controller
hardware - I don't think it's the easiest thing in the Windows world.
I did however, find a Windows API out there in the ozone (might be
what you are already using). I tried to attach it (BYW, it's in C++),
but got a message the upload directory is full. So, see below...
Thanks again. I wonder up to now how the commercial operators handled
the pause/sleep mode and coin/bill acceptors? Unless they just power
off the machine.
---------------------------------------------------------------------------
On Windows, the HidD_SetOutputReport function is used to control keyboard LEDs by sending a Human Interface Device (HID) output report to the top-level keyboard collection. For standard keyboards, this involves setting a single byte in the output report to specify the state of the Num Lock, Caps Lock, and Scroll Lock LEDs.
The process for controlling standard keyboard LEDs
Obtain a device handle. You must first get a handle to the keyboard's top-level HID collection. You can do this by using the SetupDi... functions and then CreateFile with dwDesiredAccess=0 and dwShareMode=(FILE_SHARE_READ | FILE_SHARE_WRITE).
Determine the report format. To know the correct size and structure of the output report, you can use HidP_GetCaps. This function provides a HIDP_CAPS structure, and the OutputReportByteLength member tells you the required buffer size. For a standard keyboard, the report is typically 1 byte long (plus a leading Report ID if used).
Construct the output report. You will need to create a buffer that represents the output report.
If the report descriptor does not use report IDs, the first byte of the buffer must be 0.
If report IDs are used, the first byte must be a non-zero report ID that corresponds to the LED report.
The second byte (or the first, if no report ID is used) contains a bitmask for the LEDs.
Bit 0: Num Lock
Bit 1: Caps Lock
Bit 2: Scroll Lock
Example: A value of 0x03 (00000011 in binary) would turn on both Num Lock and Caps Lock.
Call HidD_SetOutputReport. Once the report buffer is prepared, you call the function with the device handle, the buffer, and its length.
Example C++ code using the HID API
cpp
#include <iostream>
#include <windows.h>
#include <setupapi.h>
#include <hidsdi.h>
#include <hidpi.h>
#include <vector>
// Link with hid.lib and setupapi.lib
#pragma comment(lib, "hid.lib")
#pragma comment(lib, "setupapi.lib")
void SetKeyboardLEDs(HANDLE hDevice, BYTE ledState) {
PHIDP_PREPARSED_DATA ppd;
if (HidD_GetPreparsedData(hDevice, &ppd)) {
HIDP_CAPS caps;
if (HidP_GetCaps(ppd, &caps) == HIDP_STATUS_SUCCESS) {
std::vector<BYTE> reportBuffer(caps.OutputReportByteLength);
// Set the report ID if the descriptor includes them, otherwise it's byte 0
if (caps.NumberOutputButtonCaps > 0 && caps.ReportID) {
reportBuffer[0] = caps.ReportID; // or the correct report ID
reportBuffer[1] = ledState;
} else {
reportBuffer[0] = ledState;
}
if (HidD_SetOutputReport(hDevice, reportBuffer.data(), reportBuffer.size())) {
std::cout << "Successfully set LED state: " << (int)ledState << std::endl;
} else {
std::cerr << "HidD_SetOutputReport failed: " << GetLastError() << std::endl;
}
}
HidD_FreePreparsedData(ppd);
}
}
int main() {
GUID hidGuid;
HidD_GetHidGuid(&hidGuid);
HDEVINFO hDevInfo = SetupDiGetClassDevs(&hidGuid, NULL, NULL, DIGCF_PRESENT | DIGCF_INTERFACEDEVICE);
if (hDevInfo == INVALID_HANDLE_VALUE) {
std::cerr << "SetupDiGetClassDevs failed: " << GetLastError() << std::endl;
return 1;
}
SP_DEVICE_INTERFACE_DATA deviceInterfaceData;
deviceInterfaceData.cbSize = sizeof(SP_DEVICE_INTERFACE_DATA);
// Iterate through all HID devices
for (DWORD i = 0; SetupDiEnumDeviceInterfaces(hDevInfo, NULL, &hidGuid, i, &deviceInterfaceData); ++i) {
DWORD requiredSize = 0;
SetupDiGetDeviceInterfaceDetail(hDevInfo, &deviceInterfaceData, NULL, 0, &requiredSize, NULL);
std::vector<BYTE> detailBuffer(requiredSize);
PSP_DEVICE_INTERFACE_DETAIL_DATA_A deviceInterfaceDetailData = (PSP_DEVICE_INTERFACE_DETAIL_DATA_A) detailBuffer.data();
deviceInterfaceDetailData->cbSize = sizeof(SP_DEVICE_INTERFACE_DETAIL_DATA_A);
if (SetupDiGetDeviceInterfaceDetail(hDevInfo, &deviceInterfaceData, deviceInterfaceDetailData, requiredSize, NULL, NULL)) {
HANDLE hDevice = CreateFileA(deviceInterfaceDetailData->DevicePath, 0, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL);
if (hDevice != INVALID_HANDLE_VALUE) {
HIDD_ATTRIBUTES attrib;
attrib.Size = sizeof(HIDD_ATTRIBUTES);
if (HidD_GetAttributes(hDevice, &attrib) && attrib.UsagePage == 0x01 && attrib.Usage == 0x06) {
// Check for Keyboard usage
std::cout << "Found keyboard: " << deviceInterfaceDetailData->DevicePath << std::endl;
SetKeyboardLEDs(hDevice, 0x01); // Set Num Lock ON (0x01)
Sleep(2000);
SetKeyboardLEDs(hDevice, 0x02); // Set Caps Lock ON (0x02)
Sleep(2000);
SetKeyboardLEDs(hDevice, 0x00); // Turn all LEDs OFF
CloseHandle(hDevice);
break; // Stop after finding the first keyboard
}
CloseHandle(hDevice);
}
}
}
SetupDiDestroyDeviceInfoList(hDevInfo);
return 0;
}
#60
Support and Bug Reports / Re: Pause the jukebox
Last post by Barcrest - September 28, 2025, 04:50:30 PMOk, I have been working on it and have hit a stumbling block. I am hopeful to get something out tomorrow. I am having an issue with the CAPS LOCK light and getting it to toggle correctly, this has introduced some other issue with the random play and I have messed up some things. Spent a good few hours on it and think I am close to having it all up and running.